Learning C++

[Earl Chua]

Hi! I want to learn C++ on my own so I can be adequately equipped for MFE programs. How do I start?

 

[Daniel Duffy]

What's your background?

 

[Earl Chua]

I know some C, some Python, some R, and some MATLAB, but that's pretty much it. My biggest hurdle so far is navigating through syntax.

 

[Daniel Duffy]

I know some C, some Python, some R, and some MATLAB, but that's pretty much it. My biggest hurdle so far is navigating through syntax.

C and Python are relevant.

I cannot say if you can learn on your own based on what you have posted.

 

[njindian]

C and Python are relevant.

I cannot say if you can learn on your own based on what you have posted.

Hi Daniel,

I am in pretty much the same boat as Earl.

I did C, Fortran about 13 years ago but didn't use them much. Should I begin from your C++ book or is there any other text that you think I should first go through and then begin with your title. I would be joining MFE this july and was thinking of utilising these 2-3 months.

Thanks,
Nitin

 

[Daniel Duffy]

Nitin,
With C and Fortran you should have a good start.

Bruce Eckel "Thinking in C++" is a good one (and has a free legal pdf).

I am working on an updated/C++ 11 version of my book, so I would wait a while.

 

[njindian]

Nitin,
With C and Fortran you should have a good start.

Bruce Eckel "Thinking in C++" is a good one (and has a free legal pdf).

I am working on an updated/C++ 11 version of my book, so I would wait a while.

Hi Daniel,

Thanks for the prompt revert. I have got hold of the pdf of Bruce Eckel's book and will start with it.

Thanks again.

Nitin

 

[Daniel Duffy]

You're welcome, Nitin.
Good luck.

Daniel

 

[Earl Chua]

C and Python are relevant.

I cannot say if you can learn on your own based on what you have posted.

I'm sorry, but am I missing anything?

 

[Polter]

MATLAB might be relevant in picking up Eigen: http://eigen.tuxfamily.org/dox-devel/AsciiQuickReference.txt ;-)

As for the books -- I'd recommend the C++11 ones, i.e., http://isocpp.org/get-started
In particular, "C++ Primer" by Stanley B. Lippman, Josée Lajoie, Barbara E. Moo is quite good if you've programmed before.
To be honest, I like the pace of "Accelerated C++" the most (out of pretty much any programming language book, not just C++), but it hasn't been updated to C++11. Eckel (way before C++11, so naturally not updated, either) is too C-to-C++-transition specific, IMO (which might be just what one needs *if* actually transitioning from C -- and if that's the case, I'd also take a look at the C++ Annotations), but in general that's not the most common route today).

Afterward: http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

 

[Daniel Duffy]

C++ 11 is nice but it will be a number of years before it becomes mainstream, especially in legacy systems.

So, if learning C++ is a project, then 11 is not on the critical path IMO.

The new features are sooner incremental than paradigm shift and they can always be learned at a later stage. Well, that's why I would do.

 

[Daniel Duffy]

I'm sorry, but am I missing anything?

For example,

On Quantnet course there are some free videos on C/C++. Have a look. You can check your syntax knowledge against it.

 

[Polter]

C++ 11 is nice but it will be a number of years before it becomes mainstream

...but now think how much time it takes to learn C++ thoroughly ;-)

Seriously though, it's perhaps somewhat analogous to the 1998 standard -- it wasn't picked up immediately, either (major, mainstream compilers had bugs in the std. lib. implementation even years afterward), but one could already start (using HP STL, SGI STL, and later STLport), and was ultimately better served knowing the std. lib. from the start, instead of having to wait to (re)learn best practices until it became more widely adopted.

IMHO it's better to start now -- there are already a number of best practices being developed (note that Effective C++11 is already shaping up), some of them imply that what might've been a bad practice before is actually quite all right today (think of the impact of the move semantics on pass-by-value, or simple compile-time evaluation with constexpr in many cases replacing not-always-so-simple TMP), some of the good practices became even more important today (think of the impact of lambdas on the practicality of using the standard library algorithms).

Last but not least, coming from a different language (esp. R, Python, or MATLAB), I'm sure syntactic sugar, like the range-based for loop, or auto, will alleviate some of the possible frustration(s) and result in a more enjoyable learning experience

 

[Daniel Duffy]

That's a good point, Polter (yes, auto is just fab). And std::tuple<> !!

My main concern was that the student would get overflowed with lots of syntax.

and was ultimately better served knowing the std. lib. from the start, instead of having to wait to (re)learn best practices until it became more widely adopted.
Many C++ developers still only use a fraction of the functionality.
(Now I wait on Barney to ask me what I base this remark on. LOL)

 

[Polter]

Yeah, I'm especially worried about exposing beginners to dynamic memory.

I mentioned "C++ Primer" as the recommended one, since I think it covers this topic really well (this one aspect alone possibly makes it the best C++ book on the market today); over time I'm growing more convinced this is exactly how it should be done; the relevant chapter is available freely:
http://www.informit.com/articles/article.aspx?p=1944072
[PDF] http://ptgmedia.pearsoncmg.com/images/9780321714114/samplepages/0321714113.pdf

Note how unique_ptr, shared_ptr and make_shared are described and demonstrated before manual memory management -- i.e., before new and delete are even shown. Given that unique_ptr has zero overhead, a beginning programmer today really has no reason to use raw pointers with manual memory management anymore -- so it's a good idea IMHO to use this order.

Indeed, you also make a good point on std::tuple!
This is also a good example of how it makes life easier:
http://musingstudio.com/2013/04/11/...nt-operator-by-anthony-williams-at-accu-2013/
Writing operator< before could be surprisingly tricky! ;-)

 

[alain]

Yeah, I'm especially worried about exposing beginners to dynamic memory.

why? I learned memory management before learning C++. Anybody who learn C first would've learned memory management the hard way. The same applies if you learn assembly language.

 

[Polter]

why? I learn memory management before learning C++. Anybody who learn C first would've learned memory management the hard way. The same applies if you learn assembly language.

Yeah, me too. However, I think what we have to take into account in 2013 is that most aren't taking this route anymore. Chances are, more beginners today would be familiar with JavaScript, MATLAB, R, or Python before picking up C++. This results in having formed different predilections and different expectations.

So, essentially, I could stop at this point:

Given that unique_ptr has zero overhead, a beginning programmer today really has no reason to use raw pointers with manual memory management anymore

If there already is a user-friendlier feature with zero overhead, there's no reason to introduce beginners to what's unnecessary. And if they *do* need to, say, implement their own thread-safe memory pool (s.t. raw pointers may *actually* be necessary), they're not beginners anymore (and chances are they're still going to be better served by looking into Boost and/or TBB first).

This has pretty important implications on how are you going to teach the rest of C++ and in which order:
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-1-how-to-revis/240003977
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-2-how-language/240004388
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-3-smart-pointe/240004805
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-4-what-makes-a/240005166
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-5-core-languag/240005657
In particular, take a look at part 3 (and the implications on when and how to introduce copy constructors and copy-assignment operators) and part 5 (compare the string concatenation examples). A very common theme one can notice is the following (emphasis mine):

Of course we might argue that these three functions are so simple that programmers can implement those functions by themselves if they want to avoid using the standard ones. However, this strategy leads to the second problem: Both the implementation and the use of these functions requires a great deal of extra knowledge. Time that students spend acquiring that extra knowledge is time that they're not spending on learning how to solve the problems that really matter to them.

I've also been unfortunate enough to have seen too much code written by the C-first programmers, who just never knew when to stop, which might've influenced my opinion; some common issues:
- using C-style arrays for no good reason or for imaginary reasons (where, for instance, interoperability with C-APIs works often perfectly fine using std::vector instead of C-style arrays),
- writing sloppy code without expressing (and even thinking of) the ownership semantics (a code that doesn't express a distinction akin to how it's expressed by using shared_ptr over unique_ptr is simply poorly written, undocumented code -- note that I'd treat code slapping shared_ptr all over the place similarly, for the same reason) -- which then often leads to relying on the implicit (and undocumented) assumptions and problems when they invariably get violated,
- perhaps even worse offenders are the poor souls who at some point got convinced that you somehow need pointers for dynamic polymorphism (I guess poor on-line tutorials are to blame) and never got this misconception out of their heads, polluting the codebase everywhere.

In short, and somewhat tongue-in-cheek: http://klmr.me/slides/modern-cpp/

 

[Daniel Duffy]

T

Yeah, me too. However, I think what we have to take into account in 2013 is that most aren't taking this route anymore. Chances are, more beginners today would be familiar with JavaScript, MATLAB, R, or Python before picking up C++. This results in having formed different predilections and different expectations.

So, essentially, I could stop at this point:

If there already is a user-friendlier feature with zero overhead, there's no reason to introduce beginners to what's unnecessary. And if they *do* need to, say, implement their own thread-safe memory pool (s.t. raw pointers may *actually* be necessary), they're not beginners anymore (and chances are they're still going to be better served by looking into Boost and/or TBB first).

This has pretty important implications on how are you going to teach the rest of C++ and in which order:
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-1-how-to-revis/240003977
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-2-how-language/240004388
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-3-smart-pointe/240004805
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-4-what-makes-a/240005166
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-5-core-languag/240005657
In particular, take a look at part 3 (and the implications on when and how to introduce copy constructors and copy-assignment operators) and part 5 (compare the string concatenation examples). A very common theme one can notice is the following (emphasis mine):


I've also been unfortunate enough to have seen too much code written by the C-first programmers, who just never knew when to stop, which might've influenced my opinion; some common issues:
- using C-style arrays for no good reason or for imaginary reasons (where, for instance, interoperability with C-APIs works often perfectly fine using std::vector instead of C-style arrays),
- writing sloppy code without expressing (and even thinking of) the ownership semantics (a code that doesn't express a distinction akin to how it's expressed by using shared_ptr over unique_ptr is simply poorly written, undocumented code -- note that I'd treat code slapping shared_ptr all over the place similarly, for the same reason) -- which then often leads to relying on the implicit (and undocumented) assumptions and problems when they invariably get violated,
- perhaps even worse offenders are the poor souls who at some point got convinced that you somehow need pointers for dynamic polymorphism (I guess poor on-line tutorials are to blame) and never got this misconception out of their heads, polluting the codebase everywhere.

In short, and somewhat tongue-in-cheek: http://klmr.me/slides/modern-cpp/

Taking this appoach would certainly improve developer productivity.

The C-style array approach is common indeed, even arrays on the stack and static arrays.. These avoid the use of pointers..