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.
Related
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 8 years ago.
Improve this question
I'm well educated in the C++ programming language regarding syntax, STL, etc. I haven't done any true projects with it yet other than some college courses. My goal is to start writing progams but attempt to keep it to industry best practices. One of my main goals is to work in the game industry. A door is opening which lead me to ask these questions.
Are C++ game developers usually limited on using all the C++ features? Is it true more or less for each platform?
Is STL used these days in the environment, or should I avoid it?
Do they treat C++ as "everything must be an object" or is it a mix of paradigms?
Any features they tend to not use?
Is C still used, and is it good to show a project completed in it?
I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features. The idea is to keep it simple. Is this common?
Thanks in advance!
Bear in mind that "games development" covers everything from phones to websites to PSPs and DS to Wii, Xbox, PS3 and PC/Mac, so the answers you get may vary from one product/developer/platform to another.
1) Yes. Games development can mean that you have to use a particular compiler for your target platform, which may not support some of the "newer" features of C++. You may be restricted on which libraries the development studio will allow you to use. In addition, hardware restrictions on some platforms may influence how you code (e.g. on some systems the cost of virtual functions can be excessively high compared to a PC, so your designs can be restricted away from pure OO for performance reasons. Some systems have limited resources (memory, disk, etc) which will influence your design a lot. On the Playstation3 you may need to write vector-processing SPU tasks rather than traditional single/multithreaded code. etc).
2) Yes. (it's commonly used, as there's usually no point wasting time rolling your own, probably less efficient, equivalents)
3) A mix. Generally in games the key goals are (in rough order): Deliver the impossible on time (why are you going home now, it's only 10pm?), deliver high performance, and try not to crash.
4,6) Generally keep the code simple and flexible so you can develop fast and change to suit the producer's latest vision. You usually have tight deadlines so a lot of design and careful coding tends to be difficult to achieve. The industry unfortunately tends to work on the "churn out the code quickly so we can throw it away and start on the next product", although it is slowly coming around to the idea of re-usable libraries (and more methodical professional practices like unit tests, etc).
A typical scenario is to be asked to code up a quick and dirty demo for the boss, and then when you think you'll be able to throw it away and write it properly, the boss says "we don't have time to rewrite something that already works, start on the next level". So if you're asked to be quick'n'dirty, try not to burn too many bridges or you'll regret it.
5) You may use C, but it depends on the platform and the development house. These days most devlopment will be C++ even if parts of the code are effectively "little more than C" in terms of syntax and features used.
These questions are not at all unique to game development. You will find they vary as much by field as they do by company. I can think of two game design firms that use STL off the top of my head, and also of a few that don't.
1) Define "all C++ features". They typically don't use goto, if that's what you mean.
2) Yes STL is used. You shouldn't avoid it, or not avoid it - use the tools you need to get the job done every time you have a job that needs to get done. Keeping what you use in line with other ways similar problems were tackled -within that project or context- is importent.
3) Depends where you are, both in games and out of games. Some are graduated C guys who want things more C like. Others are C#/Java guys who are more OO (Object Obsessed).
4) goto
5) Yes, and yes. Knowing more than one language is always a good thing. Even if it's just C to C++.
6) Again, use the tools available to solve your problems. Keeping it simple is good when you can, sure.
1) No limitation really, except that you should follow programming guides so as to use them properly (i.e. avoid dinosaurs when using goto's).
2) Yes, its used, and Boost also (which is kinda the preview of the next STL).
3) Mix, always a mix. To say that C++ is only object-oriented is to misunderstand the language. "Everything is an object" is really a Java (or things like it) thing; check out C++'s concept of POD, as an example of how not everything is an object.
4) same as 1)
5) It is used, but as far as I've seen, no new project is being created in C.
6) No... he kinda said the opposite of what I've just said.
Generally, some parts of C++ are limited for patform and performance reasons.
Exceptions and RTTI are normally disabled. Exceptions are expensive when they unwind the stack, and RTTI uses too much memory. Lack of exceptions is particularly a pain because rather than come up with another error handling system, programmers tend to just return NULL. :)
Floats are used almost exclusively over doubles, for performance reasons.
Virtual functions and inheritence can be used, but the virtual table lookup can be costly so sometimes it's optimised out.
The STL can be used, but you normally have to write your own allocators to avoid fragging memory (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html). It's more common to see custom containers - of varying quality. I've never come across boost being used in a console project.
Most code is OO, almost to a fault.
Best C++ programming practices in professional game development environments?
The question is too broad.
Are C++ game developers usually limited on using all the C++ features? Is it true more or less for each platform?
No, or at least extremely unlikely. Depends on platform/compiler.
Is STL used these days in the environment, or should I avoid it?
You shouldn't avoid it, but:
you'll definitely need a profiler if you want stl containers
STL containers are extremely slow in debug builds. This might be a problem, because if you're frequently accessing them, there will be a huge performance drop (say, from 300 fps to 50) in debug build (when compared to release build). Debug code is already slower, and stl containers have large amount of "security check" in debug build.
Do they treat C++ as "everything must be an object"
Every idea is bad if you take it to extremes. "Everything must be an object" is one of those.
Any features they tend to not use?
Why? Unless there is a compiler bug or performance loss there is no point in avoiding feature. Besides, there are commercial 3D games written in java, so I see no point in avoiding feature of compiled language.
Is C still used, and is it good to show a project completed in it?
Some opensource projects may use C, but I can't remember a game completely written in it. There is Q3 engine, but afaik it is mix of C/C++.
I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features.
They could decide to avoid stl simply because containers are slow in debug build. It is unclear what exactly you call "advanced C++ features". Also, keep in mind that he is designer, not programmer.
The idea is to keep it simple. Is this common?
The idea may or may not be common, but it is a correct idea for a small teams. With limited human resources everything should be made as simple as possible - to reduce development costs. If you stick to concept like "everything should be an object", decide to build "nice-looking" class hierarchy, etc, AND if you have limited resources, then you are doomed - It is very possible that you'll never finish your project and will be rewriting code forever and trying to decide what should be derived from what. Needless project flexibility and extensibility may kill small project. Game engine doesn't have to be complicated.
Large teams may afford complex solutions, but complexity leads to additional bugs. For example, you could look at sims 3 - it has a VERY advanced system (object "plugins", game resource management, GPU resource management, content "streaming", etc, and I think they even put game logic into a few .NET modules that are stored within game archive...), but extensibility of the system resulted in mountain of bugs after certain updates.
Electronic Arts as one example uses STL, but felt compelled to create their own version of it called EASTL.
Are C++ game developers usually limited on using all the C++ features? Is it true more or less for each platform? These days, I think it's pretty good on the main console platforms but if you were developing for mobile devices I doubt it's quite so even
Is STL used these days in the environment, or should I avoid it? It is used and should be used... but some people don't trust it because in the past STL support was much less even, and sometimes had performance problems
Do they treat C++ as "everything must be an object" or is it a mix of paradigms? Far too general. Varies from person to person and company to company. On average, game developers have a reputation for being less focused on software engineering and more on hacking code, but that's far too generalised to really be of use. However spouting for 30min about design patterns and frameworks and abstractions in an interview is probably not a wonderful plan
Any features they tend to not use? STL still has a bad rep amongst those who worked on older platforms. Exceptions also and RTTI, probably sicne they weren't well supported (and maybe are still not)
Is C still used, and is it good to show a project completed in it? I'm sure it is, and if you have a project then show it, but it's not anywhere near as widely used as C++
I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features. The idea is to keep it simple. Is this common?
That view is pretty common but it doesn't mean it's right. You might want to tread carefully to avoid upsetting a 20-year veteran who has not moved with the times
I'm going to assume you're referring to people who develop full-price games for consoles and PC.
"Are C++ game developers usually limited on using all the C++ features?"
I think most are avoiding exceptions, RTTI, and many avoid the STL part of the standard library. They're probably using templates, though not much metaprogramming. I don't think this varies much across platform. But it does vary from company to company.
"Is STL used these days in the environment, or should I avoid it?"
It is used by many, but not all. Don't avoid it - it's a useful tool that is very good at the tasks it is designed for. Just make sure you can get by without it.
"Do they treat C++ as "everything must be an object" or is it a mix of paradigms?"
Different places will work in different ways. There's nothing intrinsic to object orientation in C++ that makes it good or bad for game development. Bear in mind that there is often legacy code or 3rd party libraries that are written in C or designed to be operated from C, so it's very rare that you'll have C++ throughout.
"Any features they tend to not use?"
I think we covered this above.
"Is C still used, and is it good to show a project completed in it?"
Yes, and no. Life is too short to spend on mastering every related language and dialect before you get your first job. Showing the ability to use a C-style library (eg. SDL) should suffice. Obviously if you set your goals on joining a company that just uses C, you will have to consider that.
"I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features. The idea is to keep it simple. Is this common?"
See above. Incidentally, game "designers" typically aren't programmers, so watch your terminology. If you apply for a game designer role, you won't usually be showing programming skills.
Has anyone tried to use the autozone garbage collector from Apple? Or can you point to a good and configurable one usable with C++?
edit: I work on decision diagrams (like BDD), so I would like to test if managing the memory with a garbage collector is efficient in this case.
edit 2: To be more precise, when implementing a library for decision diagrams, you HAVE TO implement a garbage collector. In fact, I already did this for my library, but it represents more or less 25% of the code. And it is the most complicated part :-) So yes, I want a garbage collector :-) And yes, I already use RAII techniques. And, finally, I can not afford the cost of a shared_ptr, because I store billions objects which need to be garbage collected.
Have you already analyzed if you really need an implicit garbage collection library? are you sure it is not just java (or Objective C, ...) nostalgia?
That is not natural in C++, so you will probably get into more problems than you solve. Actual implementations are mostly used in experimentation tests, and not for production apps. The best way to squeeze the potential of a language is to do things the way are tackled in that language.
Check first if explicit garbage collection (boost::shared_ptr and friends) cover your needs, and avoid introducing complexity when possible.
After Alexandre edit 2: Magic does not exist I'm afraid. Why do you think a garbage collector will be more efficient than RAII idioms.
If you don't need reference counting you can use scoped_ptr. But if you need it, you will have to pay for it, apart from how much you hide it.
Maybe your problem is allocating dinamically so many objects. If they are small ones, you will find really interesting the chapter 4 (Small-Object Allocation) of "Modern C++ Design" (Andrei Alexandrescu).
Most people tend to avoid garbage collectors in C++.
They are generally not necessary, once you learn to use RAII to manage your resources, and because C++ does not have proper support for garbage collection, the GC's that exist have a couple of problems:
They don't catch every allocation (they have to make a conservative guess of whether some allocation is referenced or not)
They may not play nice with destructors
Of course there are situations where a GC in C++ is useful. But 95% of the cases, you'll be better served simply by learning the appropriate memory management techniques (RAII) yourself.
But I haven't used Autozone, and don't know how well it works in your case or in general.
Actually, Garbage Collection was a part of the upcoming C++ 20XX standard, but was dropped for reasons of difficulty of implementation, complexity, etc...
So, sure, lots of people avoid GC in C++, but there is a strong enough demand that the standards committee is actively considering it.
Apple's AutoZone is a language agnostic garbage collector that could be bent for use with C++. Certainly, that AutoZone works for Objective-C (and C) would make for a good foundation implementation.
AutoZone is also used by the MacRuby project and, I believe, a handful of other projects. It is designed to be portable, though the implementation has bits specific to the x86 and ppc architectures -- you would need to port it to other CPU types, if necessary.
The collector has an API that can be used directly to register/unregister objects and express connectivity, etc...
It wouldn't be easy, but it is certainly doable.
No I haven't tried that. You may try this from hp labs, with more details going here. This collector works on Linux, *BSD, recent Windows versions, MacOS X, HP/UX, Solaris, Tru64, Irix and a few other operating systems.
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,
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 is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In a few weeks, we'll be teaching a crash course on C++ for Java programmers straight out of college. They have little or no experience yet with C or C++.
Previous editions of this course were just 1 or 2 half-day sessions and covered topics including:
new language features, e.g.
header vs. implementation
pointers and references
memory management
operator overloading
templates
the standard libraries, e.g.
the C library headers
basic iostreams
basic STL
using libraries (headers, linking)
they'll be using Linux, so
Basic Linux console commands
GCC and how to interpret its error messages
Makefiles and Autotools
basic debugger commands
any topic they ask about
During the course, each person individually writes, compiles, runs, and debugs simple programs using the newly introduced features. Is this the best way to learn?
Which topics do you consider most crucial?
Which topics should be added or removed?
Which topics just can't be covered adequately in a short time?
I can only once again point to Stroustrup and preach: Don't teach the C subset! It's important, but not for beginners! C++ is complex enough as it is and the standard library classes, especially the STL, is much more important and (at least superficially) easier to understand than the C subset of C++.
Same goes for pointers and heap memory allocation, incidentally. Of course they're important but only after having taught the STL containers.
Another important concept that new students have to get their head around is the concept of different compilation units, the One Definition Rule (because if you don't know it you won't be able to decypher error messages) and headers. This is actually quite a barrier and one that has to be breached early on.
Apart from the language features the most important thing to be taught is how to understand the C++ compiler and how to get help. Getting help (i.e. knowing how to search for the right information) in my experience is the single most important thing that has to be taught about C++.
I've had quite good experiences with this order of teaching in the past.
/EDIT: If you happen to know any German, take a look at http://madrat.net/coding/cpp/skript, part of a very short introduction used in one of my courses.
If they are coming from a Java world, they are used to garbage collection. As such, I'd probably spend a bit of time talking about smart (reference counted) pointers, and how they compare to garbage collection.
If you are going to put a lot of Java programmers straight out of college to write production code, I'd say the first thing you should be concerning is pointers and memory management.
Really, those who come directly from managed code rarely have the skills to debug pointer-related exception, let alone use it correctly, or even understands how their language/tools utilize it.
Pointers is how you think not just write code.
The framework and coding practices can be taught as tips and notes along the way.
But failing to understand pointers when writing C code is just waiting to shoot yourself in the foot, if not the head.
I would like to add that you should make sure to point out where they can find language and API references. In java, the API and language specification is at your fingertips online at java.sun.com... with C or C++, it's not quite as simple and easy to find reference documentation.
Whenever I am doing something in C or C++, that is my biggest problem... trying to find what I need. I usually turn to cplusplus.com, which usually has what I need, otherwise I google for it. If you have a set of references you use (online or in the form of books), list them and tell them what you use each reference for.
Memory management (pointers, allocation etc), basics of STL and templates (since STL uses templates). I think STL is important since one would be missing the richness of the Java SE class library in C++.
I would spend a whole day discussing how to write a good class in C++. Deitel & Deitel may help as a reference.
When are constructors called?
When are assignment operators called?
When are destructors called?
What's the point for const Foo & a_foo?
You should take some time on memory management, and especially RAII.