Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Is there a way to enforce the use of modern c++ 11 features from the compiler?
We have to start a new project and stay in C++ will benefit us from the use of the our existing tools and libraries, but what is currently hurting us to the death is the abuse of C style coding, raw pointers, C style vectors and all the dangerous C features that are so error prone or produce errors that are really hard to track, you know what i mean.
I read a note about what is bad in C++ today (c++11 and beyond) is the c++ past and the abuse of low level/old features when is not necessary.
I really would like to enforce from the compiler or with other tool the use of c++ 11 features like smart pointers, containers, reference parameters, c++ standard library and not C libraries, etc.
Thank you very much.
EDIT: I thought it is not necessary to clarify the use of code review. etc. I just ask if there is or not a tool/mechanism that filters creating features, or enforce modern safer features/coding practices. All the lose ends we will manage or figure out later. Thank you very much!
You might want to take a look at clang-modernize, it can help with some of what you're looking for. In addition running static analysis to help catch bad practices could help identify areas of your codebase in particular need of some attention / modernization. There are a number of such tools associated with clang and MSVC also has its own static analysis if you're working with Visual Studio.
The only way to ensure c++11 features like auto variable declarations, using lambda definitions, range based for loops, etc. are used preferred to older techniques are human based code reviews.
Usage of deprecated stuff, like usage of std::auto_ptr may be sorted out by warnings already.
But enforcing new way styles might become hard, without having a 2nd pair of experienced eyes looking at the code.
I could think of instrumenting an appropriate static code analysis tool, to detect old style patterns and propose the c++11 standard way to do it, but that's a way too broad topic, and depends on the static analysis tool used.
At the risk of getting downvoted to oblvion.
So you or your "expert" on C++ programming, want to ban certain practices.
Because you know they are bad.
One such practice is using raw pointers. Shame that there are C++ programmers who not only use pointers very often, but think they are a good thing thing to use. Guys like Herb Sutter, who in a recent talk ( CppCon I think ) said exactly that.
Another practice you mention is using C style vectors. Not a problem since C does not have vectors.
Those are really the only two that you mention. But you do talk about banning features that cause errors. That can easily be achieved. Instead of issuing your programmers computers. Issue them etch-a sketch's.
Other then that, I would say that your company should hire people who are real experts, not some guy who read a Herb Schildt book.
PS: I was trying to remember what your post smelled like, now I remember. It smells like one of those deign doc review, where one guy spend half the time arguing about spelling errors in the design docs.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have tried to keep up with C++ since they introduced 1998 ANSI/ISO C++. I absorbed the new concepts and tried to understand them. I learned about exception handling, templates, and namespaces. I've read about the new cast mechanisms and worked with the STL library.
All of these concepts required a lot of energy. But now I am somewhat worried about the future of C++ when having a look at the new C++0x standard.
Things are getting more and more complicated. This language is becoming a monster.
I'm not sure that I want to keep up with the language anymore, since I don't do my day-to-day hacking in C++ anyway. I mostly use interpreted or bytecode languages.
So why should I bother to learn this difficult, yet exceptionally powerful, language? I can do 95% of my business with Python et al. With the remaining 5%, I can deal with plain old C++ or C without hassle.
What do you think?
Everyone uses a subset of C++. For almost all application programming in C++, whether server or client side, that subset is manageable. In my opinion, the only folks that need to stay on top of absolutely every nuance of the language are the library writers -- people implementing Boost, STL, Loki, etc.
But I would absolutely use the language that fits the task. If Python is more readable and more maintainable than C++ for your job, and you don't need what C++ offers, then certainly stick with Python.
Hear what Bruce Eckel { author of the two of the so-called best C++ books } commented on C++ a few weeks ago:
That said, I hardly ever use C++
anymore. When I do, it's either
examining legacy code, or to write
performance-critical sections,
typically as small as possible to be
called from other code (my preferred
approach is to quickly write an app in
Python, then profile it and if
necessary improve performance by
calling small portions of C++ using
Python's ctypes library).
Because I was on the C++ Standards
Committee, I saw these decisions being
made. They were all extremely
carefully considered, far more so than
many of the decisions made in Java.
However, as people have rightly
pointed out, the resulting language
was complicated and painful to use and
full of weird rules that I forget as
soon as I'm away from it for a little
while -- and I figured out those rules
from first principles while I wrote
books, not just by memorizing them.
Additionally, you should read this thread and Danny Kalev's predictions on C++.
However, the growing complexity of C++ will create pressure towards splitting the language into quasi-official dialects. We can already see this trend today; it will probably intensify in the future.
EDIT:
You should take a look at this discussion, too:
C++ - Anyone else feel like C++ is getting too complicated?
First, many features of C++0x are to make the language easier to use. More readable template compile errors, more consistent initialization syntax, support for threading, which would otherwise have to rely on platform-specific libraries and so on.
So if you do use C++, I feel learning the important parts of C++0x should be a manageable task. Remember that you don't need to learn all the new features to use the language. Some features are primarily added as an aid for library implementers, for example allowing the STL to be implemented more efficiently, but which shouldn't really affect the end-users usage of the language. And some are only really necessary in very rare cases. Ignore those parts of the language.
One of their stated goals with C++0x is to avoid it becoming harder to use.
But apart from that, do you need C++? If you do your coding in other languages, why bother keeping up with C++?
You're not forced to use every feature a language provides. I don't use setjmp/longjmp in C despite it being there. I also don't use every aspect of the Java collections.
If you think the new features will make your code delivery better (faster or higher quality or both), then use them. Otherwise ignore them.
It's useful to know at a high level what they all are, if only to get you through job interviews, but half the stuff they add to languages are unnecessary in my opinion.
I never even got around to using C++ templates before switching to Java, but I knew what they were for.
It's not always about learning the latest and greatest. Software (at least at your job) is about delivery of product. That can be done in COBOL or FORTRAN if you're proficient enough at it.
No one, except maybe Bjarne and Herb Sutter, know all of C++. As you've said it's an incredibly huge language. Expecting to be able to take the entire standard + the specific implementation details of your specific compiler or compilers is truthfully unrealistic.
But you don't need to know everything in order to use C++. Instead only learn the subset of C++ that is valuable to you and your projects. It doesn't hurt to keep expanding your knowledge but unless you're writing a C++ compiler, there's no reason to know the whole thing. Even if you accomplish it, all of the people you work with won't.
So why should I bother to learn this
difficult, yet exceptionally powerful,
language? I can do 95% of my business
with python et al. With the remaining
5%, I can deal with plain old C++ or C
without hassle.
Well, for the most part you answer your own question. There is no need for you to keep up with the bleeding edge of C++ at this time.
However, the language will keep marching on. In a few years, some of the concepts you consider a bleeding-edge waste of time today will be in common use. Someday you may find during your 5% of using "plain-old C++" that some example code or code you're collaborating on uses a construct you're not familiar with. At that point, you'll need to hit the net and brush up on the new "current" C++.
Is that going to be a problem? Of course not. You're a programmer. You keep abreast of the latest programming concepts in the context of your 95% language, which also changes over time. You will likely already be quite familiar with the concepts and need only familiarize yourself with its C++ syntax when the time comes that you must use them.
Personally I hope to continue keeping up with C++, even if my career moves more toward Java or another next-gen language. Why? I would like to say because it interests me the most and because I love the complexity and expressiveness of it all. More likely, though, is just because it was my first professional language; I consider it my "native tongue".
If it does not interest you, and does not concern your job or future job, don't bother. What's wrong with that? Nothing.
Good answers.
Computer makers compete for buyers, software competes for your disk space, and languages compete for users. They do this by trying to snag each other's features.
I'm wondering how long before we see Fortran come out with lambda expressions :-)
I am hard-pressed to find a single instance where C++0x has been made more complex than C++98. There are two things which really are complex:
Concepts.
the Memory Model
but the first one has been removed again (thankfully; standardizing unimplemented features has never worked out in C++, witness throw specifications, extern templates, auto_ptr, ...), and the second isn't really something that a modern programming language can escape. It's been externally induced by Intel & Co helpfully breaking your programs to make them run faster.
The rest is just fixing annoyances that every C++ programmer has been frequently hitting in the last decades.
As a side note: I find it ... amusing ... to see how languages such as C# get packed with a database query language (LINQ) and C++ is objurgated as being bloated.
You don't need to know every standard that comes out by heart. It does help to know about the big picture though. The 5% that you do code in may have you reinvent the occasional wheel. Depending on how much time, importance that 5% has (think Pareto) you need to take a call.
Also, any particular reason (like legacy code dependency) why you can't move that 5% to python?
First try attending a course on c++0x and make your firm pay for that :)
Our brains can fit amazing amounts of junk-knowledge. Instead of cursing and having programmer-wtf-moments we should first learn from program users and listen to other people's opinions/knowhows. Knowledge transfers much faster that way.
My suggestion would be to learn the new keywords of c++0x ( && FTW) but not bother trying to learn the entire lib. Use python for w/e you want, possibly C# for apps, then use C++(0x) when you need to do something powerful. and ask stackoverflow & google about the new container when prototyping.
You dont need to use a select few language,
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Lots of the answers to C++ questions here contain the response:
"You should be using boost::(insert
your favourite smart pointer here) or
even better boost::(insert your
favourite mega complex boost type
here)"
I'm not at all convinced that this is doing any favours to the questioners who, by and large, are obvious C++ novices. My reasons are as follows:
Using smart pointers without
understanding what is going on under
the hood is going to lead to a
generation of C++ programmers who
lack some of the basic skills of a
programmer. Pretty much this seems to
have happened in the Java field
already.
Deciding which type of smart pointer
to use depends very much on the
problem domain being addressed. This
is almost always missing from the
questions posted here, so simply
saying "use a shared pointer" is
likely to be at the least unhelpful
and possibly totally wrong.
Boost is not yet part of the C++
standard and may not be available on
the specific platform the questioner
is using. Installing it is a bit
painful (I just did it using Jam) and
is way overkill if all you want are a
few smart pointers.
If you are writing FOSS code, you
don't want the code to be heavily
dependent on external libraries that,
once again, your users may not have.
I've been put off using FOSS code on
a number of occasions simply because
of the Byzantine complexity of the
dependencies between libraries.
To conclude, I'm not saying don't recommend Boost, but that we should be more careful when doing so.
Few points:
Using anything without understanding is considered harmful. But it is only the ignorant technology user (and his manager) who gets burned in the end.
You don't have to install boost to get the smart pointers - they are header only. And installation itself is rather straightforward, in the simplest approach just typing one or two commands.
Many of the Boost libraries and solutions are present in TR1 or will be present in C++0x
You will always depend on external libraries... Try to choose the one that have a bright future in terms of maintenance and support.
Unless you want to roll-out your custom solution - which would have some advantages and disadvantages.
C++ is not a novice-friendly language. With apologies to Scott Meyers, a beginner isn't learning just one language with C++, but four:
The C parts
Object Oriented parts: classes, inheritance, polymorphism, etc.
The STL: containers, iterators, algorithms
Templates and metaprogramming
I would argue that if the beginner is already climbing this mountain, they should be pointed towards the more "modern" aspects of C++ from the start. To do otherwise means that the beginner will learn C-ish C++ with regular pointers, resource leaks, etc. Find themselves in a world of pain, and then discover Boost and other libraries as a way to stem the hurt.
It's a complicated picture no matter what, so why not point them in a direction that has a positive pay-off for the invested mental efort?
As for dependencies, a great deal of Boost is header-only. And Boost's liberal license should permit its inclusion in just about any project.
Do you know how the compiler works ? Do you know how the OS works ? Do you know how the processor works ? Do you know how electronics works ? Do you know how electricity works ?
At some point you are using a black box, the question is, "is my ignorance problematic for what I am currently doing?".
If you have the taste for knowledge that's a great thing - and I clearly consider that a plus when interviewing engineers - but don't forget the finality of your work : build systems that solve problems.
I disagree. No-one would suggest that you should dive in to smart pointers without a thorough understanding of what's going on behind the scenes, but used sensibly they can remove a whole host of common errors. Moreover, Boost is high-quality production code from which a C++ novice can learn a great deal, in terms of design as much as implementation. It's not all hugely complicated, either, and you can pick and choose the bits you need.
It's impossible to understand everything thoroughly all the time. So take the word of many professional C++ developers for it that many parts of boost are indeed very useful things to use in your day-to-day development.
The inclusion of quite a lot of boost in C++0X is testament that even the team that manages the evolution of the language thinks that boost is a Good Thing (tm)
C++ is a weird, tough language. It's relatively easy to learn compared to how incredibly hard it is to master. There's some really arcane stuff you can do with it. Boost::mpl builds on some of those arcane things. I love boost, but I cringe every time I see someone in my organisation use boost::mpl. The reason: even quite seasoned C++ developers have trouble wrapping their head around how it works, and the code that uses it often reflects that (it ends up looking like someone banged code out until it worked). This is not a good thing, so I partially agree that some parts of boost should not be used without caution (boost::spirit is another example).
The C++ standard is also a weird thing. Most common compilers don't implement all of the existing standard (e.g. template exports). It's only a guideline of what to expect.
If your developer doesn't have the savvy to decide which smart pointer to use in a particular situation, perhaps they shouldn't be messing around in that part of the code without senior guidance.
There are always external libraries, starting with the run-time. A lot of boost is header-only so it does not introduce new external dependencies.
Quite frankly, for beginners I think boost isn't that well-suited. I think a beginner is better off understanding how the basics work before moving up the food chain using higher level tool/libs like boost or even STL. At the beginner stage it is not about productivity, it is about understanding. I think knowing how pointers work, being able for instance to manually create a linked list or sort one are part of the fundamentals that each programmer should learn.
I think boost is a great library. I love it. My favourite library is boost::bind and boost::function, which make function pointers much more flexible and easy-to-use. It fits in very well with different frameworks and keeps the code tidy.
I also use different Boost classes. For example, I use boost::graph to create graph classes and I use boost::filesystem for working with files inside directories.
However, boost is very complex. You need to be an experienced programmer to know its worth. Moreover, you need to have atleast some experience in C++ to understand how Boost works and implications of using Boost here or there.
Therefore, I would highly recommend looking at Boost for experienced programmers, especially if they are trying to re-invent the wheel (again). It can really be what it says on the tin: a boost towards your goal.
However, if you feel that the person asking a question is a beginner and tries to understand (for example) memory allocation, telling him to try boost smart pointers is a very bad idea. It's not helpful at all. The advantages of smart pointer classes, etc. can be comprehended only when the person experienced how standard memory allocation techniques work.
To finish off, Boost is not like learning to drive a car with automatic gearbox. It's like learning to drive on a F1 racing car.
I fully agree with you. It is the reason that i first explain them how it should be done (i.e when recommending boost::variant, i explain they should in general use a discriminated union. And i try not to say it's just a "magic boost thing" but show how they in principle implemented it. When i recommend boost::shared_ptr, i explain they would need to use a pointer - but it's better to use a smart pointer that has shared ownership semantics.). I try not to say just "use boost::xxx" when i see the questioner is a beginner. It is a language that's not just as simple to use as some scripting language. One has to understand the stuff one uses, because the language does not protect the programmer from doing bad things.
Of course it's not possible for novices to understand everything from the start on. But they should understand what their boost library solves and how it does it basically.
You can't compare this with learning processors or assembly language first. Similar it's not important to know how the bit-pattern of a null-pointer looks like. Knowledge of those are irrelevant in learning programming with C++. But pointers, array or any other basic things in C++ is not. One doesn't get around learning them before using [boost|std]::shared_ptr or [boost|std]::array successfully. These are things that has to be understood first in order to use the boost utilities successfully in my opinion. It's not about details like how to manually implement the pimpl-idiom using raw pointers - that's not the point I'm making. But the point is that one should first know basic things about pointers or the other parts a boost library helps with (for pointers, what they are and what they are good for, for example). Just look at the shared_ptr manual and try to get it without knowing about pointers. It's impossible.
And it's important to always point them to the appropriate boost manual. Boost manuals are high quality.
The consensus among almost all the answers is that boost is very valuable for experienced developers and for complex, real world, C++ software. I completely agree.
I also think that boost can be very valuable for beginners. Isn't it easier to use lexical_cast than to use ostringstream? Or to use BOOST_FOREACH instead of iterator syntax? The big problem is lack of good documentation of boost, especially for beginners. What is needed is a book that will tell you how to start with boost, which libraries are simple libraries that simplify tasks, and which libraries are more complex. Using these libraries together with good documentation will IMO make learning C++ easier.
We should encourage the use of standard canned libraries (and Boost is almost as standard as they get) whenever possible.
Some people seem to think that beginners should be taught the C side of C++ first, and then introduced to the higher-level stuff later. However, people tend to work as they're trained, so we're going to see a lot of production code written with badly managed raw pointers (well-managed raw pointers are awfully difficult sometimes), arrays (and the inevitable confusion between delete and delete []), and stuff like that. I've worked with code like that. I don't want to do it again any more than I have to.
Start beginners off with the way you want them writing code. This means teaching them about the STL containers and algorithms and some of the Boost libraries at first, so the first thing they think about when needing a group of things is a vector<>. Then teach them the lower-level constructs, so they'll know about them (or where to look them up) when they encounter them, or on the very rare occasions when they need to micro-optimize.
There's basically two types of programmers: the coders, who should be taught languages the way they should be writing them, and the enthusiast, who will learn the low-level stuff, including principles of operating systems, C, assembly code, and so on. Both are well served by learning the language they're going to use up front, while only the enthusiasts will be well served by learning from some arbitrary level of fundamentals.
I think you are mixing a lot of different concerns, not all of them related to Boost specifically:
First, should programmers (or C++ novices specifically) be encouraged to use libraries, idioms, paradigms, languages or language features they don't understand?
No, of course not. Every programmer should understand the tools they use, especially in a language like C++. However, I don't see a lot of questions here on SO where people are encouraged to not understand the code they're using. When people say they want to do X in C++, I think it's find to say "Boost has an implementation of X which works, which is more than a homebrewed solution would do, so use that".
Of course if the question is "how does X work", the question can't be answered with "use Boost's implementation". But I really don't see the problem in recommending Boost for the former kind of questions.
I also don't see how it's even possible to use Boost without understanding what's going on under the hood. C++, with or without Boost, is not Java. Using Boost in no way protects you from the complexities of the language. You still have to worry about copy constructors, pointer arithmetics, templates and everything else that can blow up in your face.
This is nothing like what happened in Java. They designed a language that removed all the subtleties. Boost doesn't do that. Quite the contrary, it has pioneered new idioms and techniques in generic programming. Using Boost is not always simple.
About the availability of Boost, I think that's a non-issue. It is available on the platforms used in the vast majority of questions, and if they're not able to use Boost, the suggestion is still not harmful, just useless.
Further, most Boost libraries are header-only and don't require you to install the whole thing. If you only want smart pointers, simply include those headers and nothing else.
About FOSS, you have a point in some cases But I'd say this is a problem for less universal libraries that users do not have. But Boost is extremely common, and if people don't have it, they should get it, as it is applicable to pretty much any problem domain. And of course, the license is compatible with any FOSS project you care to mention.
I'd rather work on a OSS project that used Boost to do the heavy lifting than one which reinvented its own (buggy and proprietary) wheels, with steep learning curves that could have been avoided.
So yeah, in some cases, recommending Boost is unhelpful. But I don't see how it can be harmful.
In any case, I don't see how it can be even half as harmful as teaching novices to roll their own. In C++, that's a recipe for disaster. It's the sole reason why C++ still has a reputation for being error-prone and produce buggy software. Because for far too long, people wrote everything from scratch themselves, distrusting the standard library, distrusting 3rd party code, distrusting everything that wasn't legal in C.
I'm not at all convinced that this is doing any favours to the questioners who, by and large, are obvious C++ novices. ...:
Using smart pointers without understanding what is going on under the hood is going to lead to a generation of C++ programmers who lack some of the basic skills of a programmer.
Do we tell novice programmers that they must learn assembly language before they get to read up on modern programming languages? They clearly don't know what's going on under the hood otherwise.
Should "Hello World" include an implementation of the I/O subsystem?
Personally I learned how to construct objects before I learned how to write classes. I think I learned how to use STL vectors before I learned C-style arrays. I think it's the right approach: "here's how to refer to several nearly identical variables using a std::vector, later I'll show you what's swept under the rug via C-style arrays and new[] and delete[]."
I disagree. Of course you will always know more about the internal workings of everything when coding it from scratch than when using 3rd party libraries. But time and money are limited, and using good 3rd party libraries such as boost is a very good way to save your resources.
I can see your point, but understanding something does not mean that you have to rewrite everything from scratch.
They are not "standard" but they are as standard as a library can get.
It is true that deploying them can be painful (but not all of the sublibraries require compilation); on the other hand they do not have further dependencies on their own, so I wouldn't be too worried about that part neither.
I agree with you, high level libraries hide things from you. It might be a good idea in the short run, but in the long run, the novice will have severe gaps in their understanding of the language.
It's easy for us non-novices to say "just use this library" because we've been down that long hard road of learning things the hard way, and naturally we want to save someone else the trouble of doing the same.
Novices SHOULD have to struggle with rolling their own low-level solutions to problems. And then, when they've got a better understanding of how their own solution worked, they can use the third-party solution, confident that they have some idea of what's going on under the hood. They'll use that library better!
I think this is a broader subject than just being about Boost. I completely regret picking up VB as my first language. If I had just started with ugly, hard to learn c, I'd be years ahead of where I am now.
I would agree with the point about smart pointers. I am a C++ beginner, and when asking a simple question about pointer syntax, one answer suggested smart pointers were the way to go. I know I'm not ready for boost (I'm not really ready for the STL either), so in most cases I steer myself away from that type of suggestion.
Scoped and dynamic resource ownership are general basic neeeds and boost's implementation of'em is very good an highly recommended. I use them a lot and they work fine.
Boost is a great library. I really hope that it grows in breadth and acceptance. Use it, extend it, and promote it.
One of the great things about the .NET community is that it has a great base class library. One of the fundemental problems with C++, I believe, is the minimalistic C++ standard library. Anywhere you go to develop code, FOSS or corporate, there is some selection of libraries that are used since there isn't a broad standard library. So you end up being a INSERT_YOUR_COMPANY_HERE C++ programmer and not necessarily too transferrable. Yes, you design/architecture skills transfer, but there is the learning curve with picking up familiarity with whatever set of libraries the next place is using. Where as a .NET developer will basically be using the same class library and can hit the ground running. Also, the libraries that are built (and reused) have a broader base to build on.
Just as an aside, you can use http://codepad.org for a code paste bin and it supports boost!
I have worked for companies who have viewed boost as library to avoid due in part to its past reputation as a poorly managed project. I know things have changed with the project, but commercial projects who want to use boost must be aware of the source of the code contained in the library, or at least be assured that they're not going to be liable for IP or patent infringements.
Sadly, the library has this reputation and it will take a while for it to break before it sees wide use in the commercial sector. I also feel this is a reason not to recommend it blindly.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know that C++ is a very complex language that takes many years of practice to master.
Taking that into account do you know of a small project (around a 1k of loc) that tests all of C++ major features (inheritance, pointers, memory management, etc).
The thing is I'm a Java/Python programmer and I really want to learn C++ so I've been studying C++ for a while but haven't tested anything of what I've learned beyond small exercises.
I want to take all of that knowledge and put into practice.
Doing this alone you will obtain many harmful habits. It's much better to get an internship with a company that has high competence in C++ development and train under guidance.
C++ is like a grenade without a safety pin – looks cool and you've heard that all "real professionals" use it, but you don't know when it is to explode. A tremendous amount of features that can be used for good or for evil without knowing whether it's really good or evil. That's why guidance is a must here.
A memory manager. That should get you thinking about:
free store management
pointers (of course!)
inheritance (you will want your driver code to use this)
templates (another way to pass the manager around -- driver #2)
designing user defined data structures (a memory block)
efficient use of standard container(s)
algorithms (to move around, figure out empty blocks, defragment)
Effective C++ and More Effective C++
Other than that, pick a (small?) personal project you want to write and do it in C++. You are not going to learn C++ by reading a 1000 line project.
I'm not sure about anything that tests all major features. There are a lot of them, and some are rarely used together (templates and virtual functions come to mind. Both achieve a form of polymorphism, so you often use one or the other depending on your needs.)
A suitable project in that it'd touch on all the important features might be something apparently simple like writing a correct container class, similar to std::vector or std::list. Ensure exception safety, iterator validity, the appropriate time complexity on all operations and every other requirement specified in the standard.
The problem with this, as well as most other projects, is that you won't really know when you're done. Making a resizable array might take 50 lines of code, and 20 minutes of your time. And then a beginner would think he's done. Making it exception-safe requires you to be able to spot all the places where the class might be thrown into an inconsistent state by an exception.
That's a kind of general problem with C++. It's easy enough to think you get it, and the compiler certainly won't notify you of aspects you've forgotten to handle. So you might think your code is perfect, and yet it'll crash for all sorts of odd special cases.
As sharptooth said, for a language as messy as C++, writing code on your own is risky. It is easy to fall into the trap of "I've written some code, it compiles and it seems to run. Therefore it is correct".
Of course you could post your code here or on other sites for review, or maybe just supplement your coding with reading the docs for actual high quality C++ code (most boost libraries tend to have comprehensive documentation, specifying both the rationale for various design decisions, and how it safely handles all the weird special cases that tend to crop up in C++. The C++ standard itself would be another excellent resource, of course. In either case, these might help you determine what problems to look out for)
When I was learning C++, I used it to write my own language for writing Colossal Cave style adventures. Like most computer languages it never saw the light of day, but it did teach me a lot about C++.
Whatever you choose the thing to avoid when learning C++ is GUI programming, which is a trap which will drain all your gumption and probably teach you bad C++ habits in the process.
I'd recommend creating a text based game. That really helped me firm up my C++. Doesn't take too long and you can exercise all the features you want. Come up with the game yourself. It is more fun that way.
Another great idea is to write a simple mathematics library, supporting Vectors Matrices etc.
But with todays libraries, that is only of academic use.
In order to learn C++ it is useful to look at a lot of well written C++ code.
I think the Qt library is quite nice for this so I suggest: Write an Qt application.
Look how they use C++ and create your own graphical components in a similar fashion.
Ideas:
- Stock chart viewer widget that connects to one of the financial websites and scrapes history data.
- Simple Excel like spreadsheet widget.
Depends on what area you want to work in. But nothing worth doing correctly comes in at less than 1000 lines of code.
If you are going to be writing games then try writing a Tetris clone.
If you think you will be using sockets etc then writing a simple chat/irc client would help.
Do you have a specific itch that needs to be scratched? When was the last time you thought "this sucks, I could do better?". Can you do better?
I would recomend writing a Tetris clone.
You can learn a lot of c++ concepts with this and learn a 2d library like SDL or maybe even OpenGL throgh SDL.
It is always good to have a project with visual results and at the end of it you can play it.
There seem to be two themes coming from the answers:
You need to pick a project that might involve more than 1K LOC in order to get the true experience of the project.
You need to also pair up with an experienced C++ developer, who can help you think through problems and avoid pitfalls associated with the language.
You can get around both of these by swing by sourceforge.net and signing up to help with an existing C++ project. As long as you don't mind your code being open source, you should be able to find an existing project to learn from plus experienced developers who can help by reviewing your code and offering guidance.
An interactive world:
A matrix where each position can be a Void or a Being.
A Being is something with a few attributes: age, Time left, gender, neigbor connections, etc. Capable a few interactions: fights, having sex and kids, friendships, etc. Some have special Skills, depending on their fathers (inherited trades)... like ability to kill, ability to make food,, etc...
Possible outcomes of those interactions and skills are changes on the self attributes, or creating offspring (when possible), or change neigbor attributes.
At each iteration, print the matrix as symbols/numbers on the console (depending on the attributes, etc), starting from a Biblical iteration 0 (initial conditions of your choice... you're God here).
Now you got some real-life pattern simulator, and learned something about inheritance, polimorfism, virtual functions, instantiation of classes, etc.
I would suggest a simple text editor would be a reasonable goal.
It's a problem domain that you have a good grasp of.
You have memory management issues, library class reuse issues (stl/curses?), pointer issues, and lots of options where derived classes can be used.
For polymorphism, perhaps, you can have the editor read from a keyboard, or suck commands in from a text file.
There is another good one.... dealing with files.
You don't have to cross platform it. You don't have to open source it. You don't have to show it to anyone. You don't even have to finish it. It can be an exercise just for you.
If you're learning fron a book, it must have plenty of well-thought-out exercises you can implement and learn from. Also check out the university sites and their C++ labs / assignments.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What free and commercial garbage collection libraries are available for C++, and what are the pros and cons of each?
I am interested in hard-won lessons from actual use in the field, not marketing or promotional blurb.
There is no need to elaborate on the usual trade offs associated with automatic garbage collection, but please do mention the algorithms used (reference counting, mark and sweep, incremental, etc.) and briefly summarise the consequences.
I have used the Boehm collector in the past with good success. It's open source and can be used in commercial software.
It's a conservative collector, and has a long history of development by one of the foremost researchers in garbage collection technology.
Boost has a great range of smart pointers which impliment reference counting or delete-on-scope exit or intrusive reference counting. These have proven enough for our needs. A big plus is that it is all free, open source, templated C++. because it is reference counting, in most cases it is highly deterministic when an object gets destroyed.
The Boehm garbage collector is freely available, and supposedly rather good (no first hand experience myself)
Theoretical paper (in PDF) about C++0x proposal for the Boehm garbage collector
It was originally said to make C++0x , but will not make it after all (due to time constraints I suppose).
Proprosal N2670 (minimal support for garbage collectors) did get approved in june 2008 though, so as compiler implementations pick up on this, and the standard gets finalised, the garbage collection world out there for C++ is sure to change...
I use boehm-gc a lot. It is straight-forward to use, but the documentation is really poor. There is a C++ page, but its quite hard to find.
Basically, you just make sure that every class inherits from their base class, and that you always pass gc_allocator to a container. In a number of cases you want to use libgccpp to catch other uses of new and delete. These are largely high-level changes, and we find that we can turn off the GC at compile-time using an #ifdef, and that supporting this only affects one or two files.
My major problem with it is that you can no longer use Valgrind, unless you turn the collector off first. While turning the collector off is easy to do, and doesn't require recompiling, it's obviously impossible to use it if you start to run out of memory.
The only one I know of is Boehm, which at the bottom is a traditional mark and sweep. It probably uses various techniques to optimize this, but typically incremental/generational/compacting GC's will be hard to create for C++ without going for a managed subset such as what you can get with .Net C++. Some of the approaches that needs to move pointers can be implemented with compiler support for pinning pointers or read/write blocks though, but the effect on performance may be too big, and it isn't necessarily non-trivial changes to the GC.
The major difficulty with GC's in C++ is the need to handle uncooperative modules, in the GC sense. ie, to deal with libraries that were never written with GC's in mind.
This is why the Boehm GC is often suggested.
You can also use Microsoft's Managed C++. The CLR and the GC are very solid and used in server products, but you have to use CLR types for the GC to actually collect - you can't just recompile your existing code and remove all the delete statements.
I would rather use C# to write brand new code, but Managed C++ lets you evolve your code base in a more progressive manner.
Read this and take a good look at the conclusions:
Conclusions
Complex solution to problem for which simple solutions are widely used and will be improved by C++0x leaving us little need.
We have little to no experience with the recommended language features which are to be standardized.
Fixing bad software complex system will never work.
Recommend minor language changes to improve future GC support - disallow hiding of pointers (xor list trick) as one example.
Finally - address the "C++ is bad because it has no GC" argument head-on. C++ doesn't generate garbage and so has no need for GC. Clearly Java, C#, Objective C, etc. generate lots of garbage.
Yes the last sentence is subjective and also a part of the holy wars.
I use C++ because I dislike the idea that someone needs to take out the garbage for me.
The city hall does that and that's enough for me.
If you need GC use another language. Pick the right tool for the right job.
Here's a commercial product I found in just looking for this same thing
http://www.harnixtechnologies.ca/hnxgc/
Back in the day, there was also a product called Great Circle from Geodesic Systems, but doesn't look like they sell that anymore. No idea if the sold the product to anyone else.