I can't help but think that people that suggest this stuff simply look at lists of features and see "lambda" and think C++ has somehow been modernized. Still fundamentally, it's producing machine code and fundamentally it has a fairly limited runtime and compared to what a LISP coder thinks of when he thinks of closures you might not want to call what C++ has 'closures.' Maybe the fact that the article referenced "lambdas and closures" is what throws me off... that's two features, right? haha The posts that mention C++'s cross platform nature also kind of make me laugh, it's sort of true, it's also remarkably easy to make it not true, just using "int" somewhere will break it some cases and if one of your platforms in Visual C++, then you'll probably have 2 code bases #ifdefed in to one, you can make it work but you have to do some work.
C++ probably won't die, not exactly that languages just die. Microsoft is all in with it, and many other organizations use it. It seems like we are in an era where there is more freedom to match the tool to the job than ever before and I can't imagine starting a medium or large scale project in C++ when Java and .NET are both still very viable. I can't imagine any serious C++ web app development, I can easily see some Ruby, Python or something other calling a chunk of C++ code, but I just can't see it rendering javascript and html in any serious way, it makes very little sense. Now VMs, runtimes, browsers, they'll likely continue to have some C++ in them for some time. It's a fine tool for some jobs. I also find is puzzling, the OpenJDK is GPL, simply Oracle's ownership somehow suggests Java is ending? If that's really what matters, then pretty clearly Go and Objective-C are what the future is, just looking at corporate ownership and momentum.
From a feature matrix? Sure C++ is the next big thing. From reality? I think and hope that it's future use shrinks and becomes more specialized.
Even if this somehow happened, allocators include protection at least in debug mode that will let you know when you're doing something obviously wrong.
Writing int won't break your program, I don't see why it would, unless you're making assumptions about range - which you shouldn't. If you need an integer of a certain length there is stdint.h
I wonder if it'd make sense to develop a Coffee Script style language that compiles a "sane" subset of C++, gets rid of some of the nasty\annoying aspects of C++ (header files), and helps enforce good C++ coding practices (const correctness) but is close to C++.
The result hopefully won't feel like a nano-management attempt, while people will think twice before they make anything "mutable".
What I was proposing is a C++ compiler that could enforce a specific subset of standard C++, along with making things that are generally regarded as best practices default. Because of the complexity of C++ it might have to be a somewhat simplified version of it to work (something like http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...).
1. cross platform
2. the programmer can choose from several levels of abstractions, as appropriate for a particular project: low-level c-style coding, OOP, templates, meta-programming.
3. even the very high level abstraction usually doesn't induce performance penalty.
4. not using some property of the language doesn't induce performance penalty ("you pay only for what you use" principle).
5. New ISO C++11 standard makes the language even stronger
6. Many design decisions can be expressed by using templates or multiple inheritance, and enforced during compilation.
From internet discussions, I noticed that quite a few people under-appreciate the points 2) and 3), or don't have good understanding about why abstractions are an important part of software design (especially in larger projects).
Also, even in 2011, in a lot of projects the performance achievable only by native code is still very desirable or even required.
2. Just use 2 languages, like C + Lua. or C + anything-higher-level-than-Java. As a "language", such a combination is easily simpler than C++, and the high level part is way cleaner. My point is, don't use one complex tool when 2 simpler one can do.
On a side note, you should think about what OOP, templates, and "meta-programming" are good for. Most of the time, naked lambdas and closures solves OOP's problems in simpler ways. Templates solve parametric polymorphism (or "genericity"), and meta-programming is just a buzzword, as far as C++ is concerned. (When it is not a buzzword, the systems behind are so huge than I wonder if it's worth the effort, see the Boost library.)
3. That one sounds like a lot of work. A high-level and efficient abstraction has to be build from a fairly low level. Efficient memory management for instance, will probably be more complicated than the straightforward (but copy-ridden) RAII scheme.
6. Properly thought out type systems enforce better, and in a simpler way. See Haskell for instance. And even if your high level language is very permissive (Lua, Lisp…), you could still write a custom preprocessor. Not too daunting, as long as the syntax you pre-process isn't C++'s.
That's why it will still be around 5, 10 and 20 years from now - as long as there's something for everyone to dislike it will also make enough people happy enough to continue using it.
I think the number of applications where C++ is an appropriate choice for a new project is a lot less now than it was 10 years ago.
Generally a higher level language (Java, C#, Python etc) should be looked at first in most cases, but I am sure C++ will have its niche for a while yet. Like games for example.
Cross platform could indeed be one of those niches, but just being native isn't that big a deal. Python and Java to give a couple of examples are just as compelling options in most cases.
Look at Java today with it's language ecosystem; scala, clojure, jruby, ...
I can't imagine Java and .NET developers moving to C++ much less enterprises changing course.
Some of my more interesting projects are C++ based so i have a feeling it's going to stick around for quite a while yet.
The only real use for C++ I still see is high performance gaming. And I hope that dies out in favor of real games.
I think most people complain that C++ is overly complex because they try to learn it at the same time they try to learn a complex (typically GUI ex. MFC) framework. If you're learning C++ start with backends. Strip it down so that there aren't so many things to learn initially.
The same thing could be said for any language worth a darn. It stands out more for C++ because it's typically only used in heavy lifting situations. It's almost impossible to learn and produce something coherent in this case. Again though that would be true for any language suitable for such situations.
There are tons of people who think they know C++. There are a smaller subset that do.
If you get people who A> Refuse to follow the subset of the language your group is using on the project or B> deeply misunderstand one or two features, you're in total utter hell if you can't fire the person.
Most places don't have an easy enough ability to fire people to do C++ in my opinion, therefore C++ is not suitable for them.
Most other languages it doesn't matter anywhere near as much, as idiosyncrasies can be cordoned off well, but with C++, anyone doing anything strange or incompatible anywhere is a problem for most everyone. That same power and control is a curse when people are controlling things two different ways.
In a bigco which takes 6 months to fire someone, this is killer to a project. One guy can destroy a project in that timespan.
C++ has it's place, and that place is "where we can afford pretty high salaries and fire those people who don't work out quickly".
Writing boost heavy code vs STL code vs object oriented code vs prototype based code vs highly functionally styled code vs custom allocated code vs reference passed code vs smart pointer code, interface based code vs heavily multiple inheritance based code vs flat hierarchy mixin template based polymorphism etc.
It gets expensive to keep people who do all of that around with the level of correctness you need to not have weird bugs that take forever to find. It usually means "You have few domain experts" on the team as well (for if the project is say, for financial software, or RF controllers, or modems, etc).
I do think we'll see languages that espouse some of the same guiding principles of C++, namely: multiple paradigms, only paying for what you use, native compilation options, and compile-time metaprogramming.
As it stands now, it has a huge marketing problem that's been perpetuated by a meme of "omg complexity!!!!!111," (aside: it's goofy how fashion-oriented developers are) so C++ in its current form could never rise up.
If I could only have one programming language, it would definitely be C++. I can do anything with it on any operating system. No vendor or IDE or build environment lock in. It's a solid ISO standard with multiple compiler support.
I still use bash, Python and Ruby for quick test scripts and prototyping and I like them as well.
Compare to C, where everything is heavily standardized and you can use libraries from different compilers without much difficulty.
It sucks, in many ways, but it's what we have.
Every other complaint I have against the language just stems from my familiarity with C++ and love of static typing (or compiler hints and syntactic niceties useful for writing high performance code - namely games).
If we extrapolate (obligatory: http://xkcd.com/605/) present trends it seems that the platform of the future will be the web.
This will require fast internet connections on computing devices (whatever those will look like in 10 years) as pervasive as water and electricity in the rich world. And we are getting there.
So the language of the future will be based on this platform. The obvious choice then would be javascript. But javascript has a lot of problems so most likely someone will invent a language of the form javascript++ within a few years.
There's so much that can change in one year let alone five or ten, therefore it isn't easy to make predictions that far out.
For the record I use C++ in a day job, and there's an awful lot of code written in it, so it will exist in some form or other for a very long time to come. Need I mention COBOL? There's also enough stuff written in Java, C#, Visual Basic, JavaScript, Ruby, and Python for them to easily last into the next decade.
But at the same time, developers will prefer working in higher-level (more productive) languages whenever possible.
So, IMHO, C++ is a language of the future, not the language of the future.
I really hope people will stop doing such silly things, but realistically, it's unlikely to change too soon.
Lately, I've found the ugliness inescapable and deeply irritating:
for (std::vector<mytype>::const_iterator i = myinst.begin() ...
for (auto i = myinst.begin() ...
I've recently been doing a bit of C# coding again. I'm stunned at how quickly I get get stuff working, mostly because .Net contains all the boilerplate I would either write myself, or have to track down in 3rd party libraries. I wrote a page scraping tool the other day in C#, on my Mac, in vim, with the Mono C# compiler. I had it done in under an hour, and it runs on both platforms I use. My productivity increased by about 8x (clearly not universally applicable), and my enjoyment increased even more.
So, no, C++ probably isn't the future. The future probably looks like Python and Javascript on the web, C# in business applications, and plain C at the bottom.
Your statement is false, because the choice of language depends on the job. For example, when I need to make something simple quickly I will do it in C#. However when I need to write an add-on to an existing application that doesn't have an official plugin system, then C++ and Assembly are really awesome.
Complicated + robust + easy to maintain is plain impossible in C++. Also, add-ons fit "enhance software" better than "building software".