Getting a solid grip on C++ : Where to go next?

Studying stuff for the sake of studying doesn't go anywhere in my opinion. You just have to know that a feature of a language exists and what it does, but if you want to actually learn something, you should establish yourself a project to work on. Clearly set up a goal for you: I want to do an application that does that and that. Design it and then start working on it. Pretty early in the development process you will hit some problems, and then you will have to find solutions for them. This is the best way to learn a programming language. Languages are tools that help you achieve your goals, they have no purpose by themselves. So studying a language out of a clear context (like making an application) is pointless.

You should first of all learn what you are comfortable with and what you will need, or what you think you'll need. If you can easily afford the extra time, by all means go for C++, but otherwise it may be wiser to perfect your skill in C# (since you've been doing this for two years).

C++ is great (C++ is my favorite language, and I greatly dislike managed languages) but a good C# programmer is much better than a mediocre C#-and-C++ programmer. Or, a mediocre C#-and-C++ programmer who knows some C.

Also, even a mediocre C# will be able to produce a working program faster than a good C++ programmer! The C++ program may run 5% faster overall (or it might not, depending on the implementor's skill!), but usually people will not notice that at all. The C# program will take much longer to start, but people are used to that. You get your stuff out early, though -- which is a marketing advantage. On the other hand, if you plan to get a job where C++ is needed, C# obviously won't get you far.

With that said, if you are going to persue C++, you will be surprised that what people consider "good C++" is not that far away from managed code, except you do the management explicitly. You will often/usually use RAII, smart pointers, and containers to the same net effect. The one big difference is you do the "managed" bit explicitly. C++ follows the old philosophy "only pay for what you use", so you are strictly not required to do one or the other thing. It is perfectly "allowed" (not considered good, but allowed) to use raw pointers.

You will also notice that the standard library is not as large as the one supplied with C# and it is quite a bit harder to use. No worries, though... it contains everything that you truly need, and you will get used to the usage. It may seem weird at first, but once you get behind its reasoning, you'll see that it's actually quite ingenious.

What you should most definitively know about is how to write exception-safe code (read up on RAII and the different types of smart pointers, how they work and what they do, Google and Wikipedia can work wonders for that, even without owning a textbook), the exact workings of the inheritance system, const correctness, and of course, the standard library (you need to understand at least the most important classes and concepts, such as vector, and map (and know, at least in principle, that there are some others, and roughly what they do -- but in 90% of all cases vector works just fine anyway), how to use iterators, and how to use an algorithm that takes a functor).

Marshall Cline's C++ FAQ has a stunning amount of valuable information that helps you avoid the most stupid mistakes, and it's written in a way one can understand very well, too (in my opinion). Sutter's Mill is a good reading once you feel like you're sitting in the saddle a bit firmer -- probably not for beginners.

Thanks for the tips samoth! As a matter of fact I do intent to hopefully land an internship somewhere within the next 1-2 years. Tall order? Maybe but its worth a shot. And I don't mind learning new stuff anyway.

If you're new to memory allocation then you'll want to read up on the difference between the heap and the stack, as well as how and why to use each. That will give you a very solid grounding to work from.

I've found that learning the "building blocks" of the language to be the most essential in really coming to understand how c++ works. Knowing what pointers are and how they work is a good place to start. You need to know the difference between between allocating memory on the heap and allocating it on the stack and what that means for the scope of a variable or object.

When I first started programming in c++ I didn't truly understand the difference between what a reference is and what a pointer is, or I would get myself in trouble by believing my vector or data structure held references to certain objects when they actually just held values(I came from a mostly Java background).

My advice is to just sit down and program some of the very basic data structures. Program a linked list, a hash map, a binary tree, etc... Building these data structures in any language will give you an intuitive idea as to how memory is managed. Build your data structures and use them in a small project and use a tool like memcheck to observe any memory leaks. In the future you will likely try to avoid managing your own memory, by using smart pointers and what not, but knowing how to manage memory yourself is really key to understanding c++.

Hope this helps!

I have found this to be a decent source for C++

http://www.learncpp.com/

I've found that learning the "building blocks" of the language to be the most essential in really coming to understand how c++ works. Knowing what pointers are and how they work is a good place to start. You need to know the difference between between allocating memory on the heap and allocating it on the stack and what that means for the scope of a variable or object.

When I first started programming in c++ I didn't truly understand the difference between what a reference is and what a pointer is, or I would get myself in trouble by believing my vector or data structure held references to certain objects when they actually just held values(I came from a mostly Java background).

My advice is to just sit down and program some of the very basic data structures. Program a linked list, a hash map, a binary tree, etc... Building these data structures in any language will give you an intuitive idea as to how memory is managed. Build your data structures and use them in a small project and use a tool like memcheck to observe any memory leaks. In the future you will likely try to avoid managing your own memory, by using smart pointers and what not, but knowing how to manage memory yourself is really key to understanding c++.

Hope this helps!

Just did a quick look at that site and it follows the same mistake that many (most) C++ books have made. When C++11 came along ( and even leading up to it ), "good" C++ changed. Pretty much any resource that doesn't mention RAII within the first few chapters is fail and should be avoided. These C++ texts that are in their 5th+ revision that simply treated the changes to the language like this site did, by stamping it on at the end, well, they failed. They are teaching the language poorly out of laziness about wanting to update.

C++ has gone through a number of revisions over the years. Starting as a language built over that compiled into C, then templates, then STL and now C++ 11. Each of these advances pretty much obsoleted the books that came before it. That said, you still see tutorials/books that are treating C++ as a better C, using C style string functions for example. Ditto you see books teaching you naked pointer usage in the first couple chapters. In the 25+ years C++ has been around, it has changed a great deal... what I am saying is make sure you are dealing with a learning resource that has been updated to reflect those changes, instead of just bolting them on at the end.

Just did a quick look at that site and it follows the same mistake that many (most) C++ books have made. When C++11 came along ( and even leading up to it ), "good" C++ changed. Pretty much any resource that doesn't mention RAII within the first few chapters is fail and should be avoided. These C++ texts that are in their 5th+ revision that simply treated the changes to the language like this site did, by stamping it on at the end, well, they failed. They are teaching the language poorly out of laziness about wanting to update.

C++ has gone through a number of revisions over the years. Starting as a language built over that compiled into C, then templates, then STL and now C++ 11. Each of these advances pretty much obsoleted the books that came before it. That said, you still see tutorials/books that are treating C++ as a better C, using C style string functions for example. Ditto you see books teaching you naked pointer usage in the first couple chapters. In the 25+ years C++ has been around, it has changed a great deal... what I am saying is make sure you are dealing with a learning resource that has been updated to reflect those changes, instead of just bolting them on at the end.

Good points!

I removed the link. While I don't think it is a bad resource I do agree that it is outdated.

Yeah it's not a bad source, just potentially dangerous to a beginner.

Also, even a mediocre C# (programmer) will be able to produce a working program faster than a good C++ programmer!

I feel like that difference shrinks as the caliber of the programmer goes up. Will a really good C++ and C# programmer be appreciably faster when working in C#? Not sure. C++11/14 with extensive use of standard libraries (and good 3rd party libraries) can be very expressive, and also pretty safe if you choose to use a safe coding style (which may or may not come at a performance cost). Certainly it's faster to write some things in C++ compared to e.g. Java, even for a klutz like me.

At the low end of skills the difference is the most striking. I think it's accurate to say that a poor C++ programmer will generate negative value to a project. With C++, either plan to get pretty good, or spend your time more constructively with another language.

Also, even a mediocre C# (programmer) will be able to produce a working program faster than a good C++ programmer!

I feel like that difference shrinks as the caliber of the programmer goes up. Will a really good C++ and C# programmer be appreciably faster when working in C#? Not sure. C++11/14 with extensive use of standard libraries (and good 3rd party libraries) can be very expressive, and also pretty safe if you choose to use a safe coding style (which may or may not come at a performance cost). Certainly it's faster to write some things in C++ compared to e.g. Java, even for a klutz like me.

At the low end of skills the difference is the most striking. I think it's accurate to say that a poor C++ programmer will generate negative value to a project. With C++, either plan to get pretty good, or spend your time more constructively with another language.

If you mean faster as in programmer productivity, then yes, a really good C++ and C# programmer will be faster in C#, often by an order of magnitude. That's a side effect of the purpose behind each language. The design principals behind C++ of pay for what you use and that undefined behavior should be decided by the programmer has a cost on productivity.C# doesn't follow this ethos at least not as closely. As a result things like runtime type information is just much more accessible in C# and more pervasive in the libraries.

Oh, and of course that is the biggest productivity win of C#. As languages, C# and C++ aren't really all that different. Some aspects of C# are much cleaner due to the newness of the language ( generics for example ), but at the end of the day this isn't the stuff that profoundly effects productivity. (Although spend a weekend working with LINQ and you will have a hell of a time going back!) Nor really is memory management, the normal big boogieman. No, the big difference is the standard libraries. C++ has improved quite a bit since STL then Boost, but compared to C#, they are absolutely shit. Sit a great C++ programmer down beside a great C# programmer and ask them to accomplish many common programming tasks... read an XML file, string manipulation, parse and transform data, make a network connection, archive and expand a file, etc... and the C# programmer will generally spank the C++ programmer. There are exceptions and edge cases, but they are just that.

Then of course are all the other little things that add up as performance wins. The compile/link cycle for example. The lack of cruft is another big win in C# ( and to a much lesser degree Java ). These things all contribute to programmer productivity.

Personally I think people put too much emphasis on "perfect" learning, where in reality it differs on the individual. For instance, is it a good idea to stick to one language when you're starting out? Well yes, it is, because it usually implies someone is simply "hung up" on whether the language is good enough to learn or not. Does that mean you shouldn't learn another language for the heck of it? Of course not, myself in particular I learned rather early on that sticking to one thing is very challenging for me, and the best way for -me- to become a better programmer was actually to try new things. Even working on a project when I got really tired of being stuck on something, i'd stop and look up some other programming concept I was curious about, maybe AI or networking or a language I'd wanted to learn. It's refreshing in a way, and you always learn a new little thing doing it.

Basically what I'm saying is that if you think you'll get something out of C++ then don't be afraid to dip your fingers into the language, I can guarentee you that it won't -hurt you- to learn another language, especially one thats about as bare metal as you can go without being assembly. My personal experience with learning has been that one book, one language, one library, one project, none of them teach you everything about them, you learn a lot of the most important information by accident while learning something completely different sometimes. At he very least it may help something "click" in another language, "Oh THATs why they do that in C#!" sort of thing.

Pogrammers tend to have this little problem(myself included many a time) that they learn so many little things in order to understand a concept that when they have to explain it to someone or direct someone they don't remember those thousands of little things they had to accidently learn in order to understand it. Knowing anything in coding is usually a -lot- of information, like there's a difference between knowing pointers and really KNOWING pointers. These things are often best learned by ones self.