Other Software > Developer's Corner

Why C++ Is Not “Back”

<< < (2/2)

mouser:
For me, the major problem with the new C++0x is that it's hard for me to see the audience for it.  It seems to me to be almost a last gasp that is going to turn into more of a poison pill..

C++ is my native language -- i've been coding in c++ for 25+ years, and I still love it.

But I just don't see the new stuff being added as satisfying anyone.

If you really want to dig into the more modern programming language ideas.. you are not going to want all of the legacy backward-compatibility messiness that C++ is committed to supporting.  The backward compatibility is one of the real strengths of C++ but it makes the language much less clean.

And on the other side of the coin, if you are coding in C++ because of the backward compatibility stability and large code bases, and are attracted to the lean and mean C++ principles, then all of these new features in C++0x are probably not only things you weren't wanting, but may cause you some concern that you're now going to have more incompatibility issues with old compilers, etc.

It seems to me that the new C++0x may really just hasten the extinction of C++.  I'm just hopefull it will help inspire the next breed of programming languages.

mouser:
Perhaps a better way to say what i was trying to say is that, C++ is now trying to do two things that are very fundamentally at odds with each other:

It is trying to continue the C++ tradition of being strictly backwards compatible, for which it pays a very heavy price in terms of simplicity and consistency, while at the same time trying to absorb the more modern advances in programming language design.

Trying to do both of these things feels to me like you are courting disaster.

And you have to ask yourself -- who is clamoring for this?  The people who want to use modern programming language features don't want to be tied to ugly backwards compatibility compromises.  And the people for whom backwards compatibility is of top importance, I can't imagine they would welcome all of these new features.

There is a big market for modern programming language design -- C++0x is never going to be at home here because of all the cruft baggage it has to carry from its past.  And there is a smaller market for legacy C/C++ code -- this market is not going to be thrilled with these new features.

I just don't see an audience for C++0x.

Now I still think there *IS* a market for a new modern programming language that embraces the control over resources and the emphasis on performance that C++ has always focused on. That's something that I've been waiting a long time for.  But it's not going to be C++0x, it's going to be a new language that doesn't have to carry the baggage of backward compatibility that C++0x is burdened with.

Jibz:
Languages like D, Go, and Rust are often mentioned in the context of systems programming languages.

mouser:
I gave D a good long look a while back.. it's definitely got the feel of an evolved C++, but didn't quite do it for me, and I have concerns about its longevity.

Never heard of Rust, going to give it a look.

I'd love to be involved in designing a new modern language that could capture the spirit of C++..

mwb1100:
The biggest problem with C++ is that it lacks a large, high level standard (or standard enough) library for things like network communication, file and directory operations (beyond reading and writing files).    In C++ you have to decide if you want to roll your own or choose from one one of several competing alternatives and get it integrated into your build system.  Boost is the closest thing to this, but even Boost is far from universally used.

Then if you pull something down from the internet that looks to be useful, you have to make sure it'll work with your chosen library/libraries, decide to port it to those if necessary, or pull in yet another dependency (and hope there are no conflicts).

All of this exists for other languages to some extent, but it's far worse for C++.  Herb Sutter has indicated that a focus for the next stages of C++ standardization will be to try to extend the library to address this:

I’ve been beating the drum this year (see the last section of the talk) that the biggest problem facing C++ today is the lack of a large set of de jure and de facto standard libraries.-http://herbsutter.com/2012/06/02/facebook-folly-oss-c-libraries/
--- End quote ---

There's also an indication that the C++ standardization process will try to move somewhat faster than the historically glacial pace it's taken in the past:

ISO C++ standardization is accelerating. Major companies are dedicating more people and resources to C++ standardization than they have in years. Over the next 24 months, we plan to ship three Technical Specifications and a new C++ International Standard.-http://herbsutter.com/2012/11/03/talk-now-online-the-future-of-c-vc-iso-c/
--- End quote ---

Both of these goals are probably more difficult with C++ than other languages because C++ standardization is pretty truly a committee driven process - there is no single stakeholder that can dictate things as there is for most other languages. But it appears that many players in the C++ standardization process are trying to move it along (http://www.isocpp.org). Unfortunately, people who work on GCC don't seem to be represented very strongly at isocpp.org. Possibly because there's a significant cost - Gold at $10,000 per year, Silver at $5,000 per year, or Bronze at $1,000 per year.

Navigation

[0] Message Index

[*] Previous page