Is modern C++ becoming more prevalent? [closed]

Answer 1

Many teams I've been on and heard about consider the big "are we using exceptions?" question. This is code for "are we using modern C++?"

Once you aren't using exceptions, you are precluded from using the full power of the language and its libraries.

But many older codebases are exception-less, and it is perceived to be difficult to shoehorn exceptions into a codebase that doesn't expect them, or into a team that doesn't know how to use them, so the answer in such cases is often 'no.'

In my experience, modern C++ needs someone who is passionate about it on the team, who can't stand the sight of anything less, to push for it. It also needs to overcome the objections of those who want it to be more like the legacy code.

While I don't think that old-C++ codebases are going away very quickly, I do believe there are more of these passionate people in the world than there were five years ago. They face the same uphill battle they faced five years ago, but they are more likely to find kindred spirits.

Answer 2

It's amaizing how little effort goes into making c++ more stable. The warning system is in place, but it's not evolving much. It's even easier to shoot yourself in a foot than it was 10 years ago. Dont know why, but c++ is still my favorite language. :)

Answer 3

Absolutely yes. To me if you're not programming C++ in this "Modern C++" style as you term, then there's no point using C++! You might as well just use C. "Modern C++" should be the only way C++ is ever programmed in my opinion, and I would expect that everyone who uses C++ and has programmed in this "Modern" fashion would agree with me. In fact, I am always completely shocked when I hear of a C++ programmer who is unaware of things such as an auto_ptr or a ptr_vector. As far as I'm concerned, those ideas are basic and fundamental to C++, and so I couldn't imagine it any other way.

Answer 4

In my C++ jobs, I've found the modern features to be increasingly used, and more people asked me about them in phone screenings and interviews. As far as I can tell, they're catching on.

I learned C++ originally as something like C with Classes; although the language had advanced far beyond that, the books I read and people I worked with were firmly stuck on "old C++". RAII something people would think about, rather than automatically do, and I remember reading some of the early articles on the problems of exception safety.

As pointed out, there's new books out now. Many of the old ones are still relevant, but they increasingly seem to be full of explaining why obviously bad ideas are bad. (Similarly, it's hard for modern readers to understand how revolutionary Freud's ideas of an unconscious mind were, since it's now conventional wisdom.)

Stroustrup just came out with a textbook, Programming: Principles and Practice Using C++. I bought it because I haven't yet failed to learn good stuff from a book of Stroustrup's, but haven't gotten past the first few chapters. So far, all I can say is that I approve of the way he's starting out, and it's at least a good introduction to how C++ should be used.

Answer 5

I wouldn't say that std::vector qualifies as "modern" these days. It is really basic.

Generally my impression is that people have gained some experience with modern C++ style and sobered up a little. Just to take a simple example, STL for_each was interesting but in practice it does not add a terrible lot of value over a plain C loop. It is harder to debug and sometimes does not provide the best performance. Also the constructs for functional programming in current STL are generally very cumbersome, especially if you got experience from a real functional language like ML.

Answer 6

The standardization of the language in the late 1990s was the first step, it allowed the compiler makers to focus on the "standard" set of features, also allowed the language to fix some of the rough edges, which appeared trough the standardization process.

This in turn allowed development of frameworks based on standard features of the language, and not on features provided by a particular compiler implementation. The Boost library is notably in this regard. Also this permitted that new development is based on previous work, thus making possible solutions to more complex problems.

A notable change here is how previously frameworks were based on the notion of base classes and derivated classes (a run time feature). But now most advanced features often are heavily based on "recursive" templates (a compile time feature).

The STL has its pros and cons but it survived the test of time, if you want something that works and is simple STL surely has something to help you start. There's no point in reinventing the wheel (unless for didactic reasons).

Computer hardware has also made great leaps from the 1990s, then the memory and CPU are no longer a constraint for the compiler. So most of the theoretical optimizations from books are now possible.

The next steps of the language is the support of multi-core programming, which is part of 0x standard effort.