How can I become an expert at C++ quickly?
February 5, 2005 9:16 AM Subscribe
How can I become an expert at C++ quickly? I know that the real answer is "lots of experience and work", but I would appreciate some tips on how to get from here to there as efficiently as possible. [MI]
I know how to write small programs in C++, and I consider myself to be very proficient in Java, so I don't need help with the basics.
I do need help with figuring out what I don't know that I don't know about. I know I don't know memory management, C++-specific conventions, compilation/linking or creating libraries.
Any book suggestions, online resources, or good programming projects?
I know how to write small programs in C++, and I consider myself to be very proficient in Java, so I don't need help with the basics.
I do need help with figuring out what I don't know that I don't know about. I know I don't know memory management, C++-specific conventions, compilation/linking or creating libraries.
Any book suggestions, online resources, or good programming projects?
Best answer: I learned C++ (and Java, actually) from C++ In Plain English. (There's a Java and a VB and several other versions of it too.) It will take care of things like memory management and general syntax stuff; linking and library creation are more platform-specific though. I came to it from a C background though so my concept of pointers in C was fairly stable anyway, but it did a good job of reteaching and going over iterators and stuff. As a plus, it's a pretty frooping complete reference book too, language-wise (it doesn't do much STL stuff, I think). The tutorials are well written and easy to read and follow, and each one pretty well stands on its own so you can just read the ones on memory management and skip everything about what a class is. :-)
posted by mrg at 10:07 AM on February 5, 2005
posted by mrg at 10:07 AM on February 5, 2005
Um, if you already know Java you're already 90% there. Now it's just a matter of syntax and learning all the booby traps and poison pills that C++ has in order to prevent developers from being any kind of productive. Take a week and read Stroustrup's The C++ Language, Josuttis' The Standard Template Library, Lakos' Large Scale Software Development, and all the Scott Meyers' Effective C++ books. Start banging out tiny little programs and become familiar with your toolset. Start scoping out and learning all the libraries you need. If you are an above average Java head you should be able to be able to become an expert* in C++ in about a month.
* Note that nobody is an expert in C++. The language is so complex and messy that nobody understands more than 80% or so of its features and capabilities--including the creator.
posted by nixerman at 10:11 AM on February 5, 2005
* Note that nobody is an expert in C++. The language is so complex and messy that nobody understands more than 80% or so of its features and capabilities--including the creator.
posted by nixerman at 10:11 AM on February 5, 2005
I disagree with most of the the previous advice -- Stroustrup's book is great once you already know the language, not when you're trying to learn it.
Put the STL stuff on hold for now. What you really need to concentrate on is memory management. And get used to having to find leaks and seeing the words "core dump."
I've been dealing with C++ for quite some time, and nixerman is correct: nobody understands more than 80% of the language.
The book C++ Primer is very good. It's usually used for beginning Comp. Sci. majors.
posted by hummus at 10:35 AM on February 5, 2005
Put the STL stuff on hold for now. What you really need to concentrate on is memory management. And get used to having to find leaks and seeing the words "core dump."
I've been dealing with C++ for quite some time, and nixerman is correct: nobody understands more than 80% of the language.
The book C++ Primer is very good. It's usually used for beginning Comp. Sci. majors.
posted by hummus at 10:35 AM on February 5, 2005
Part of what makes C++ difficult to learn (and teach) is that it's hard to learn incrementally; in some ways you have to understand all of it in order to understand any of it.
Some sources I've found helpful: Bruce Eckel's great Thinking in C++ can be downloaded (although you'll probably end up buying a printed copy). I also second Scott Meyers' Effective C++. I didn't find reading Stroustrup that helpful; it's mostly a description of the language and doesn't delve into practical issues. Dietel & Dietel's textbook has a lot of excersises that might be of interest to you but it's not a good reference, is not well organized, and is painfully badly designed (it must have 25 different typefaces invarious colors).
posted by TimeFactor at 10:38 AM on February 5, 2005
Some sources I've found helpful: Bruce Eckel's great Thinking in C++ can be downloaded (although you'll probably end up buying a printed copy). I also second Scott Meyers' Effective C++. I didn't find reading Stroustrup that helpful; it's mostly a description of the language and doesn't delve into practical issues. Dietel & Dietel's textbook has a lot of excersises that might be of interest to you but it's not a good reference, is not well organized, and is painfully badly designed (it must have 25 different typefaces invarious colors).
posted by TimeFactor at 10:38 AM on February 5, 2005
Best answer: Short answer: you can't. It's hard.
Your best bet is to study a bunch of the seminal books. I third Scott Meyers -- try both Effective C++ and More Effective C++. When you're ready, the best Standard Library/STL book I've seen is The C++ Standard Library: A Tutorial and Reference by Josuttis. I agree that Stroustrop is only useful as an advanced book. Another good place for really advanced C++ learning are the proposed ANSI standards.
Another big help is mentorship. C++ is full of features that just aren't for beginners. It can really help to have someone around to tell you what not to do.
It's also important to stay humble. C++ still suprises people who've programmed in it for 10 years.
While he gave some good advice, don't listen to nixerman about Java and C++. Java and C++ share common syntax but the syntaxes only overlap by about 70%. More importantly, their runtime models are vastly different. C++'s runtime model is what makes it challenging. Also, Stroustrop really does understand C++, but he's one of only a few who do.
posted by maschnitz at 10:51 AM on February 5, 2005
Your best bet is to study a bunch of the seminal books. I third Scott Meyers -- try both Effective C++ and More Effective C++. When you're ready, the best Standard Library/STL book I've seen is The C++ Standard Library: A Tutorial and Reference by Josuttis. I agree that Stroustrop is only useful as an advanced book. Another good place for really advanced C++ learning are the proposed ANSI standards.
Another big help is mentorship. C++ is full of features that just aren't for beginners. It can really help to have someone around to tell you what not to do.
It's also important to stay humble. C++ still suprises people who've programmed in it for 10 years.
While he gave some good advice, don't listen to nixerman about Java and C++. Java and C++ share common syntax but the syntaxes only overlap by about 70%. More importantly, their runtime models are vastly different. C++'s runtime model is what makes it challenging. Also, Stroustrop really does understand C++, but he's one of only a few who do.
posted by maschnitz at 10:51 AM on February 5, 2005
I learned C++ immediatly after learning C, so I can't help you much with your transition. What I will say is that you need to start communicating directly with someone who knows C++ well. Usenet or other discussion forums can work well for this. C++ seems to make sense, until you start digging deep. Once you get a bit more experienced, you'll need the help of an old hand to make sense of the various inconsistencies that will sneak up on you. Otherwise, you'll start going crazy when nothing does what you think it should.
posted by JZig at 11:56 AM on February 5, 2005
posted by JZig at 11:56 AM on February 5, 2005
I strongly reccomend Accelerated C++ by Koenig and Moo.
This book *starts* with the STL. It provides a gentle but fast-paced introduction.
The STL is very powerful; some aspects of the STL are easy to use; why not get comfortable with it right away?
I agree that Stroustrop's book is not for beginners.
posted by funkbrain at 12:05 PM on February 5, 2005
This book *starts* with the STL. It provides a gentle but fast-paced introduction.
The STL is very powerful; some aspects of the STL are easy to use; why not get comfortable with it right away?
I agree that Stroustrop's book is not for beginners.
posted by funkbrain at 12:05 PM on February 5, 2005
I went from C++ to Java years ago, and still do some of each. The biggest difference, I think, is in memory management -- most of the other major differences are syntactic. Memory management is evil. This will be a major hurdle when moving from java, which does the memory management for you (not to mention the related task of preventing illegal memory access). In C++ you'll have to do it by hand. Whenver possible, you should stack-allocate data in C++. If you really need to use pointers, the references above will get you pretty far, but it's a good idea to have a good memory debugger on hand, because once you get into really complicated memory management stuff, you are bound to encounter some kind of hair-pulling error that was caused by an improper write to a pointer in some far-flung location.
posted by casu marzu at 12:19 PM on February 5, 2005
posted by casu marzu at 12:19 PM on February 5, 2005
Best answer: Stroustrup's The C++ Programming Language 3rd ed.: a reference and a primer;
Stroustrup's Design and evolution of C++ : knowing why C++ is how it is gives you great insight into how to use it;
Scott Meyer's Effective books: what not to do;
Coplien's Advanced C++ Idioms: old, published in 1992, but very valuable form a design perspective;
Alexandrescu's book on templates, Modern C++ Design is simply mind-blowing.
And spend a lot of time browsing comp.lang.c++, comp.lang.c++.moderated, and comp.std.c++.
Your questions will be answered in comp.lang.c++, good questions will be answered with incredible rigor and detail in comp.lang.c++.moderated (and bad questions will be flamed mercilessly), and comp.std.c++ will just make your head hurt.
posted by orthogonality at 12:57 PM on February 5, 2005
Stroustrup's Design and evolution of C++ : knowing why C++ is how it is gives you great insight into how to use it;
Scott Meyer's Effective books: what not to do;
Coplien's Advanced C++ Idioms: old, published in 1992, but very valuable form a design perspective;
Alexandrescu's book on templates, Modern C++ Design is simply mind-blowing.
And spend a lot of time browsing comp.lang.c++, comp.lang.c++.moderated, and comp.std.c++.
Your questions will be answered in comp.lang.c++, good questions will be answered with incredible rigor and detail in comp.lang.c++.moderated (and bad questions will be flamed mercilessly), and comp.std.c++ will just make your head hurt.
posted by orthogonality at 12:57 PM on February 5, 2005
Response by poster: Great, thoughtful advice, everyone. I've picked up both Effective C++ books already and find them excellent.
I plan to use my C++ knowledge to program games on a pseudo-professional basis. I.e., I'm not quitting my day job but I'd like to release what I make. I know that most modern games are written in crappy, do-whatever-it-takes C++, but I'd like to know how to develop maintainable, extensible, bug-free programs right from the start.
Plus, once I graduated, I became much more interested in learning things. :-)
posted by breath at 1:13 PM on February 5, 2005
I plan to use my C++ knowledge to program games on a pseudo-professional basis. I.e., I'm not quitting my day job but I'd like to release what I make. I know that most modern games are written in crappy, do-whatever-it-takes C++, but I'd like to know how to develop maintainable, extensible, bug-free programs right from the start.
Plus, once I graduated, I became much more interested in learning things. :-)
posted by breath at 1:13 PM on February 5, 2005
Oh, and nixerman's advice isn't really on target: Java is far more similar to C than C++ (objects notwithstanding), and Java suffers from a pointer aliasing problem that is largely absent in C++.
C++ tries very very hard to make every object be, or at least act as if it is, a local ("automatic") variable that can be assigned a value, even when it isn't, really; Java, with all its immutable wrappers, ties very hard to go the other way. The consequence is that in C++, you're often manipulating locals or things that act like locals, and which clean themselves up after local scope is exitted. In Java, you're playing with pointers to the heap, and you're often getting more than one pointer to the dame heap object -- and thus you have more problems with pointer aliasing.
Despite similar syntax, the mind-set required for effective, efficient design is very different in the two languages: stuff that works and is idiomatic in C++ (e.g. RAII) doesn't work in Java, and stuff that is efficient in C++ (e.g.pointers to function) is not efficient in Java.
Java in fact uses as idioms certain things that are assiduously avoided in C++ -- e.g, Java includes istanceof as an operator, and encourages its use. C++ reluctantly includes dynamic_cast, intentionally makes using it ugly, and intentionally makes it not work on classes without virtual functions.
This difference because C++ knows that RTTI is expensive, and C++ only charges the programmer for features he uses. Java goes the other way, preferring additional runtime costs in favor of making programming easier and more consistent. One is not necessarily better than the other, but if you're going to pick your poison, it's good to know what poison you're picking. Another reason to read Stroustrup's D&E.
The sum total of these differing design goals is that Java really is more like C -- and tends to attract programmers who use it like C -- than it's like C++.
To use C++ effectively - to be an "expert" -- you have to think in C++ terms. And to do that, it's important to read and understand Stroustrup -- especially his D&E book. Using C++ "as Java" is generally a mistake -- like using a screwdriver as a hammer -- that leads to frustration and users complaining that "C++ sucks" compared to Java.
posted by orthogonality at 1:19 PM on February 5, 2005
C++ tries very very hard to make every object be, or at least act as if it is, a local ("automatic") variable that can be assigned a value, even when it isn't, really; Java, with all its immutable wrappers, ties very hard to go the other way. The consequence is that in C++, you're often manipulating locals or things that act like locals, and which clean themselves up after local scope is exitted. In Java, you're playing with pointers to the heap, and you're often getting more than one pointer to the dame heap object -- and thus you have more problems with pointer aliasing.
Despite similar syntax, the mind-set required for effective, efficient design is very different in the two languages: stuff that works and is idiomatic in C++ (e.g. RAII) doesn't work in Java, and stuff that is efficient in C++ (e.g.pointers to function) is not efficient in Java.
Java in fact uses as idioms certain things that are assiduously avoided in C++ -- e.g, Java includes istanceof as an operator, and encourages its use. C++ reluctantly includes dynamic_cast, intentionally makes using it ugly, and intentionally makes it not work on classes without virtual functions.
This difference because C++ knows that RTTI is expensive, and C++ only charges the programmer for features he uses. Java goes the other way, preferring additional runtime costs in favor of making programming easier and more consistent. One is not necessarily better than the other, but if you're going to pick your poison, it's good to know what poison you're picking. Another reason to read Stroustrup's D&E.
The sum total of these differing design goals is that Java really is more like C -- and tends to attract programmers who use it like C -- than it's like C++.
To use C++ effectively - to be an "expert" -- you have to think in C++ terms. And to do that, it's important to read and understand Stroustrup -- especially his D&E book. Using C++ "as Java" is generally a mistake -- like using a screwdriver as a hammer -- that leads to frustration and users complaining that "C++ sucks" compared to Java.
posted by orthogonality at 1:19 PM on February 5, 2005
Response by poster: Yeah, when I was writing some of my early programs, I always used the new operator to create objects. I just didn't think that you could create them any other way. Needless to say, I'm sure they were leakalicious.
I kind of wish that C++ function arguments were const references by default, and you had to explicitly say if they were not. That seems like it'd save some grief (and typing!)
posted by breath at 3:13 PM on February 5, 2005
I kind of wish that C++ function arguments were const references by default, and you had to explicitly say if they were not. That seems like it'd save some grief (and typing!)
posted by breath at 3:13 PM on February 5, 2005
I'm a non-programmer who's been kabitzing over programmer shoulders for a while and just took a job that will require some light C++ coding (altering templated files for data recording purposes. This thread popped up at a great time for me. I've done an online course and the part I had the most troulbe with was memory management, so reading the comments here makes me feel a little better.
In fact, just got back from Half Price Books with C/C++ Programmer's Reference by Herbert Schildt. Was it worth the $5 I paide for it?
Anyway, thanks for all the recommendations; this thread will make a great bookmark.
posted by Doohickie at 3:58 PM on February 5, 2005
In fact, just got back from Half Price Books with C/C++ Programmer's Reference by Herbert Schildt. Was it worth the $5 I paide for it?
Anyway, thanks for all the recommendations; this thread will make a great bookmark.
posted by Doohickie at 3:58 PM on February 5, 2005
Doohickie asks, [is the] C/C++ Programmer's Reference by Herbert Schildt... worth the $5 I paide [sic] for it?
NO! NO! NO!
Schildt is pure evil. $5 is about $1005 too much.
He doesn't know C++, and he thinks that an old DOS compiler sets the standard for the language.
Seriously, it'll do you more harm than good to read Schildt. Throw it out, don't even open it, it's like that necklace in The Exorcist.
posted by orthogonality at 4:38 PM on February 5, 2005
NO! NO! NO!
Schildt is pure evil. $5 is about $1005 too much.
He doesn't know C++, and he thinks that an old DOS compiler sets the standard for the language.
Seriously, it'll do you more harm than good to read Schildt. Throw it out, don't even open it, it's like that necklace in The Exorcist.
posted by orthogonality at 4:38 PM on February 5, 2005
Based on breath's second comment about wanting to write good code, I highly recommend Writing Solid Code by Steve Maguire. It's geared more towards C programming, but it's full of logical, really good coding habits.
posted by Sibrax at 5:56 PM on February 5, 2005
posted by Sibrax at 5:56 PM on February 5, 2005
It's worth mentioning that because of C++'s self-inflicted, near-complete backwards-compatibility with C, which Stroustrup later regretted, and because of recent, somewhat radical evolution in the language philosophy, C++ has something of a split personality. For this reason, when people talk about C++, they might mean subtly different things.
It's perfectly possible to write C++ code that could be called "C with objects", using an extremely minimal set of features. Indeed, the earliest versions of C++ in the 1980s were little more than that. But as time has gone by, C++ added templates, exceptions, namespaces, new-style casts, the boolean type, stream operators, and the STL.
For a while, compiler vendors aggressively competed in supporting the new 1998 standard, but as the spec stabilized and technologies like Java and COM and the web became the new shiny things, nobody seemed to care much anymore. Because of the slow adoption and widespread incompatibilities, C++ has gotten a reputation for being less portable than C -- code compiled with Visual C++ might not compile with Borland's compiler, for example; but even these were quite well-developed compared to compilers offered by proprietary Unix vendors such as IBM and Sun.
In addition to this reputation, many people have tried using the new features and ended up shooting themselves in the foot through overuse or overdesign, the same way people got burned, back in the old days of the OO craze, on developing complex class hierarchies. (Microsoft, for example, has a well-documented history of trying to use C++ and OO and later going back to the drawing board.) When you have a shiny new hammer, everything looks like a shiny new nail.
For these reasons, many programmers recommend against using the full set of C++ features -- a lot of programmers use classes and heap-allocated objects, but shy away from templates and the STL. Most toolkits, such as Qt, go for this common-denominator approach. And indeed, companies/teams often have a policy which -- either formally or informally -- prohibits the use of certain features such as templates.
But these restrictions go against the fundamental philosophy of the "new C++", which is heavily based on generic programming, ie. template classes and template functions. With this newfangled style of programming, you can do many compile-time tricks that make C++ work more like a functional language than the old imperative one we know and love. To me, some of this template magic (there's some really amazingly odd stuff in Boost, if I remember correctly) comes across as too clever for its own good, and awfully unreadable. But it's a powerful language, and if used correctly, you can be productive with it.
posted by gentle at 6:39 PM on February 5, 2005
It's perfectly possible to write C++ code that could be called "C with objects", using an extremely minimal set of features. Indeed, the earliest versions of C++ in the 1980s were little more than that. But as time has gone by, C++ added templates, exceptions, namespaces, new-style casts, the boolean type, stream operators, and the STL.
For a while, compiler vendors aggressively competed in supporting the new 1998 standard, but as the spec stabilized and technologies like Java and COM and the web became the new shiny things, nobody seemed to care much anymore. Because of the slow adoption and widespread incompatibilities, C++ has gotten a reputation for being less portable than C -- code compiled with Visual C++ might not compile with Borland's compiler, for example; but even these were quite well-developed compared to compilers offered by proprietary Unix vendors such as IBM and Sun.
In addition to this reputation, many people have tried using the new features and ended up shooting themselves in the foot through overuse or overdesign, the same way people got burned, back in the old days of the OO craze, on developing complex class hierarchies. (Microsoft, for example, has a well-documented history of trying to use C++ and OO and later going back to the drawing board.) When you have a shiny new hammer, everything looks like a shiny new nail.
For these reasons, many programmers recommend against using the full set of C++ features -- a lot of programmers use classes and heap-allocated objects, but shy away from templates and the STL. Most toolkits, such as Qt, go for this common-denominator approach. And indeed, companies/teams often have a policy which -- either formally or informally -- prohibits the use of certain features such as templates.
But these restrictions go against the fundamental philosophy of the "new C++", which is heavily based on generic programming, ie. template classes and template functions. With this newfangled style of programming, you can do many compile-time tricks that make C++ work more like a functional language than the old imperative one we know and love. To me, some of this template magic (there's some really amazingly odd stuff in Boost, if I remember correctly) comes across as too clever for its own good, and awfully unreadable. But it's a powerful language, and if used correctly, you can be productive with it.
posted by gentle at 6:39 PM on February 5, 2005
Indeed, the earliest versions of C++ in the 1980s were little more than that...
The first C++ compiler I encountered (MPW C++, 1990ish) was actually a C pre-processor. It'd parse the C++ and output C code (lots of structs with pointers to functions).
posted by TimeFactor at 7:09 PM on February 5, 2005
The first C++ compiler I encountered (MPW C++, 1990ish) was actually a C pre-processor. It'd parse the C++ and output C code (lots of structs with pointers to functions).
posted by TimeFactor at 7:09 PM on February 5, 2005
Don't.
I mean, learn the basics, but most games could be written with java, with some low-level stuff written in C, or C++.
posted by delmoi at 7:46 PM on February 5, 2005
I mean, learn the basics, but most games could be written with java, with some low-level stuff written in C, or C++.
posted by delmoi at 7:46 PM on February 5, 2005
Response by poster: Thanks for the suggestions. I have programmed (pretty fun) games in both Java and Flash, but I want to "move on" to larger programs written in C++. Maybe this is a waste of time, but I feel like learning something new can't hurt me.
Lots of great tips on how to pick up C++, thanks everyone.
posted by breath at 9:48 AM on February 6, 2005
Lots of great tips on how to pick up C++, thanks everyone.
posted by breath at 9:48 AM on February 6, 2005
off topic, but if you're looking for a language that is fast, can be used for serious development, supports oo programming (amongst other things), and which will teach you more, you might consider ocaml. it's the only functional (ish) language (apart from scheme/lisp, arguably) that gets a serious amount of commercial use. it's a modern, well designed language with automatic memory management and static typing (which means that it's simply *impossible* to get the two largest classes of errors that make c/c++ programming so frustrating). it's supported on windows and unix, and has decent tools (profiling tools and a debugger in which you can not just do all the normal things, but also step/jump *backwards* in time).
posted by andrew cooke at 10:38 AM on February 6, 2005
posted by andrew cooke at 10:38 AM on February 6, 2005
I started out with C++ for Dummies and found it a very good primer. I actually went back and reread it about a year later.
Scott Meyers' books have proven invaluable since then. I bought the CD and have it installed on all my systems.
I certainly don't feel proficient at all, and based on this thread better pick up a few more references!
posted by jacobsee at 12:06 PM on February 7, 2005
Scott Meyers' books have proven invaluable since then. I bought the CD and have it installed on all my systems.
I certainly don't feel proficient at all, and based on this thread better pick up a few more references!
posted by jacobsee at 12:06 PM on February 7, 2005
« Older How can I keep my flash drive synced to a specific... | How likely is it that this person lied to me about... Newer »
This thread is closed to new comments.
posted by reynaert at 9:58 AM on February 5, 2005