Today, reading an article on popular C++ myths [1], I now realized there are a TON of things I didn't realize modern C++ can do now. auto, unique_ptr, for_each, and range-for loops were new to me. I'm not 100% certain if all of these were recent additions to the language.
What are some things I can do to brush up on the modern features of C++?
[1] https://isocpp.org/blog/2014/12/myths-1
Go and do a trivial project in it, cppreference.com and cplusplus.com have c++11 tags on the new features. I'm sure you've had ideas recently and I'm sure the project is less trivial than you thought!
I think looking at language features first is "a solution looking for a problem" attitude.
I'm sure there are some people that think this will be OK; after all, lots of people say you don't really have to understand templates unless you're writing a library (and so on). But I don't think it will be OK. There was very little in C++98 (that I knew well, at the time) that it was OK not to know; unless you knew all of it, pretty much, you couldn't really use any of it safely. (This is how Scott Meyers makes his living.) I can't imagine C++11 will be any different; I might not know it well, but I do note that it has many of the same people behind it.
Thank you for perhaps the best summation of everything wrong with using C++ in a project, and everything wrong with C++ as a language!
templates, as you say yourself you're ok not to know. you're also not ok not to know exceptions.
there's other stuff too, you can get away without the C preprocessor. C++ is too big to know all of and it's a waste of time to invest time trying to, unless you are on a standards committee or are writing a compiler...(and even then you can get away with being a specialist!).
it's much better to be a program writer than a language lawyer and dare I say it: more satisfying too.
i draw a huge distinction between people that understand a language and people that can use a language, and i think people underestimate the time and effort in understanding a language. i think that time and effort could be better spent writing programs.
I'd take a book like Scott Meyer's new Effective Modern C++ book (which I recommend) and focus on applying one item every week. At the start of the week read through the item. Every time you write code for that week make an effort to see if that item applies to what you're doing. Maybe read the item again midweek or towards the end of the week to see if the practical experience changes your view on what he wrote. The book contains 42 items so if you go through it like this you'd be done in less than a year.
I'm not saying that people shouldn't read the whole book at once. However, if you just read it through once and put it on the shelf I don't think you'll get the same benefit that you would get from spending time focusing on individual areas.
I think of any language as another tool in my toolbox. The better I know a tool, the better I know when and how to apply it to a specific problem.
I'd wager that just one trivial project won't fully demonstrate the personality and capabilities of a language.
http://www.amazon.com/Effective-Modern-Specific-Ways-Improve...
IMO its better than the Bjarne Stroustrup book (which i've read too), but any of the two is fine to learn modern C++ features.
I recently read it and it's great. The book has less than 200p, but still covers the most important parts of C++11, albeit not in great detail (the reader is pointed to "The C++ Programming Language" by the same author for that). Read it! And watch the youtube video in [1].
[1] https://www.youtube.com/watch?v=xnqTKD8uD64 [2] http://www.amazon.com/Tour-In-Depth-Series-Bjarne-Stroustrup...
http://stackoverflow.com/tags/c%2b%2b11/info
http://stackoverflow.com/tags/c%2b%2b14/info
Don't get me wrong. The new features are great. I love nullptr, fixed width integers, to_string, stol, etc. but I sometimes work in environments with very old compilers that don't offer these features. And when the only code you have is written for C++11 or newer, it can take a great deal of time and effort to make your code work on the older systems.
Also, if what you need is in the standard, then don't use any external libraries. There are a lot of great libraries out there (Boost, Crypto++, etc.), but they add complexity and build dependencies and can cause all sorts of support issues. If you add Boost only because you need to parse arguments, then you're really causing yourself and developers who come after you more trouble than it's worth. So every time you think you need an external library, think twice and talk it over with other, more experienced developers.
When I need more features than the older standard provides, I'll use a newer standard, but I strive to only use the exact features I need (don't go wild and convert your entire code to C++11). And as a very last resort, I'll use an external library (but only a mature, widely used one) when I cannot easily write what I need with std C++.
Hope this helps. And whatever you decide, I'm sure you'll enjoy working with C++.
Here is a somewhat off-topic question for you: what is the job market like for C++? Is it mostly maintaining/enhancing legacy code or is there considerable new code being written in C++?
When I worked in systems programming (automobile systems research), C++ was very popular in the embedded/systems space. I believe it still is. Many systems people I knew were porting C to C++. Old code was maintained and new code was written. I'd say the break-down was about 50 50. In addition to adding C++ features, maintaining C compatibility was paramount.
I never worked with higher-level applications, but I'm sure that there's a lot of C++ up there too (web browsers, office suites, etc). Maybe even more.
Well, that's no longer true - Rust and Go are two contenders for C++'s "niche". They are still growing, but are already much nicer languages than C++. In some situations Erlang or Ocaml can also replace C++ successfully.
Some things are hard to come by in any shorter sources. And at times you have to dig into the standard.
An example of rather obscure thing in C++ which changed in C++11 (sequencing): http://en.cppreference.com/w/cpp/language/eval_order
And another thing which can be pretty confusing without carefully reading the standard. Copy elision vs move constructors...
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n324... § 12.8 (Copying and moving class objects), #32 - 33
Bjarne has never had such pretense and his writing also reflects his personal style. And he will tell you quite honestly that some distasteful aspects exist because C++ was a language created to be used (backwards compatibility is a feature, adding keywords/syntax only when necessary, etc) not that "nothing is wrong."
Any rational discussion of programming languages is one of relative merits, applicability to specific problems, and personal prefs, rather than one of absolute truths.
Functions (other than lambda functions) with trailing return types, e.g. writing auto foo() -> int; instead of int foo();, because of a desire to preserve stylistic consistency with the many existing function declarations.
Compile-time rational numbers (<ratio>), because of concerns that it's tied to a more template-heavy interface style.
The <cfenv> and <fenv.h> headers, because many compilers do not support those features reliably.
Default lambda captures.
[0] http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...
"C++ Primer", by Lippman is the book that we try to follow.
I will be curious to read the replies here, as a year ago I was considering different languages and environments for a cross-platform project, and ultimately C# (yes, C#) won out over C++. To be fair the requirements for the project meant that runtime performance wasn't so critical, but preventing the developer - myself! - from making mistakes was.
Maybe it is because of my age, but despite having lots of experience with C++ and a mostly pleasurable love-sometimes hate attitude towards it, I couldn't imagine it making first choice for me these days for new projects.
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012
https://github.com/daniel-j-h/cpp14-snippets https://github.com/daniel-j-h/cpp11-snippets
(Disclaimer: the C++14 version is still missing proper references to the official C++14 standard)
Also, this talk would give you a very general overview of the new features of the language:
http://channel9.msdn.com/Events/GoingNative/2013/Opening-Key...
Another book that can be a refresh introduction would be:
http://www.amazon.com/Tour-C--Depth/dp/0321958314/ref=sr_1_1...
After reading these two books it definitely changed the way I see and work with C++, I fell in love with it.
So reading old code-bases is very common, you still need to understand the old C++ anyway:
Professional C++, Wrox, Jan 2005
Then to get yourself up to speed with C++11 and C++14:
Professional C++ 3rd Edition - Wrox, Sept 2014
"Effective Modern C++" goes more into the details and is next on my queue.
I've done a bunch of Ruby, Java, and some Lisp programming since my last stint with C++. It feels like a whole new language.
If you just want to skim - A Tour of C++ should suffice.
Totally worthy.
I hate C++ with passion for almost two decades. But I recently started working on KDE sub-project and found it very nice.