A Deeply Skeptical Look at C++0x

http://importantshock.wordpress.com/2008/08/20/a-skeptics-look/

by Anon84 • 18 years ago

30 32 18 years ago

importantshock.wordpress.com

> Okay, it needs to be said. C++0x is an astoundingly terrible name. People have named projects and initiatives poorly before, but this takes the cake: it looks like an automatically-generated password. Only two of its five characters are alphabetica, and it doesn’t even make sense - what is a hexadecimal prefix doing at the end?

Somebody missed the point of the name... C99 was C9x before it was officially accepted in 1999; C++0x will likely end up as C++ 09 when it (perhaps) gets accepted next year.

huhtenberg5• 18 years ago

> Somebody missed the point of the name

Actually, the whole rant is largely just a rant, quite clueless and poorly argued in places (e.g. nullptr vs NULL). However, it's hard not to agree that auto function and lambda syntax (the -> and [] things) and rvalue references are astonishingly bad additions. It's obvious that Boost people have very strong influence on a committee, because hardly anyone else outside of Boost needs these features.

scott_s6• 18 years ago

  for (std::vector<int>::const_iterator i = vec.begin(); i != vec.end(); ++i)

Versus,

  for (auto i = vec.begin(); i != vec.end(); ++i)

How is auto an astonishingly bad addition again?

Rvalue references solve a problem that library writers who are concerned with performance have. That most programmers don't need rvalue references misses the point - most programmers will probably depend on a library that benefits from rvalue references.

fh• 18 years ago

nullptr vs NULL

I'm not sure if the author knows this, but the fact that nullptr is even needed is a design flaw of C++. That is,

    int foo = NULL;

is illegal C, but legal C++. So much for C++ being more typesafe!

newt0311• 18 years ago

The article makes quite a few good points. Then again, thats not very hard with C++.

swombat• 18 years ago

It can be quite hard actually... point(er) arithmetic is pretty complicated.

orib3• 18 years ago

He makes very few good points. There is much to mock about C++, but he hasn't hit on any of them. Actually, it's pretty clear by some of his comments that if he's used C++, his knowledge has long rusted ([] to initialize arrays? sorry. no. that's {}. If you're critiquing a language, please learn it's syntax first.) Anyways, let's take a few points where he totally misses the ball:

  Please, please don’t add language features just to make
  the lives of library designers easier. Add features to
  make the average programmer’s life easier.

     Seriously? You don't think that being able to write 
     libraries that integrate with the language seamlessly
     will make the programmer's life easier? You think that
       std::vector<int> blah;
       blah.push(0);
       blah.push(1);
       blah.push(2);
     beats
       std::vector<int> blah = {0,1,2};

  ...The fact that in contravention of who-knows- 
  how-many-years of tradition, return type is going 
  after the function and parameter names?

     Hey, just like every functional language that you
     spent the last few paragraphs praising. If you'd
     complained about it being inconsistent, you may have
     even had a point! something like
        int anon(...){...}
     would probably have been a cleaner syntax, despite
     being hell to parse (what in C++ isn't hell to 
     parse, though?)

I could go on, but I've got stuff to do. Still, if you're going to rant, please make it a well-informed rant! For the most part,the C++ FQA still applies to C++0x, among many others; plenty specific to C++0x

This really reads like a "WAHH! C++ isn't Python or Java!" post. only by someone that barely passed his C++ class in college.

Edit: Fix up formatting.

ConradHex• 18 years ago

> This really reads like a "WAHH! C++ isn't Python or Java!" post. only by someone that barely passed his C++ class in college.

I agree with many of your points, but I think that last bit is unnecessarily harsh.

scott_s6• 18 years ago

A lot of people don't like C++. I get that. What I don't get is why people feel personally affronted by the changes. All of the language extensions address real problems that have been faced by real programmers.

C++0x is the solution a large group of people came up with to answer a lot of problems. Articles like this one are written by people who appear to be largely ignorant of these problems. The implicit assumption here is "I'm smarter than the C++ committee." If you think that, then you should wade through the documents produced by the committee and see how you would solve these problems: http://www.open-std.org/jtc1/sc22/wg21/

orib3• 18 years ago

You forgot the biggest problem; You don't want to force several hundred millions of lines of code to be rewritten, of you want the porting to be trivial and the changes to cause compile failures ("oh. sorry. we've turned that into a keyword now; change the name" sort of porting)

scott_s6• 18 years ago

I actually didn't list any problems, but I know the committee thinks of backwards compatibility when considering new features. Pick one of the documents and you'll probably find it mentioned.

As an aside, I think that C++ has gone too much out of its way to not introduce new keywords. That's why, for example, the syntax for lambdas looks odd and reuses previous tokens, and the new nullptr keyword is not just "null." If you're unwilling to break old programs, then you can never clean up; think OSX vs. Windows, or even Python's willingness to break compatibility with version 3.

ajross• 18 years ago

You're looking at the wrong level of abstraction. The C++ standards committee is no doubt a group of very smart people. But they're trying to "evolve" C++ by adding every feature under the sun. It doesn't matter how smart you are; if you try that, you'll make a mess. In fact, the very fact that these are smart people might be blinding them to the fact that they're designing a language to be used by mere mortals.

Really, C++ started simply. Early cfront languages were delightful, IMHO (with a few warts, like "protected", which in hindsight were a mistake). It was C, but with a pleasing syntax for class encapsulation and virtual function dispatch. I still write most of my C++ in that language.

But then we got multiple inheritance, and operator overloading, and placement new, and constructor initializer lists, and koenig lookup, and RTTI, and templates, (pause for breath) and now garbage collection, and synchronization, and lambdas. When will it end!? Every one of this changes is justifiable in isolation, but the end result is a language that almost no one actually understands (literally: I'm not sure I know anyone in my professional circle with a solid grasp of the entirety of C++ -- contrast that with the fact that almost everyone knows C more or less perfectly).

timr• 18 years ago

" It was C, but with a pleasing syntax for class encapsulation and virtual function dispatch. I still write most of my C++ in that language."

Then you aren't using the language -- you're using C with classes. Which is fine, but don't make comments as though your usage patterns reflect the mainstream. C++ has moved well beyond C, and it's a different language now.

IMO, the roots of C++ in C are both its biggest strength, and its greatest liability. Sure, this ensures compatibility with a ton of old code, but this compatibility also adds lots of ugly warts to the language syntax. Moreover, to this day, lots of C coders are fooled into thinking that they're dealing with a language that's "C plus a few features", and they're invariably shocked when it turns out to be a totally different (and more powerful) programming environment. They then tend to complain loudly on the internet that the language is a disaster, without ever really trying to understand it for what it is.

jey• 18 years ago

Digital Mars D is nice if you really must write systems software. It's a cleaned up C++ and has garbage collection thrown in, but you can do anything you can do in C (like drop down to malloc() and free() when needed).

jimdesu• 18 years ago

I agree that the article's not too great -- I think that the big bang-for-the-buck for most of these features (except closures) will do is make for much cleaner, more streamlined library support that'll make day to day "hey this module's terribly boring but it needs to be written" code much nicer.

Addition of closures, on the other hand, will make C++ a viable back-end target for a lot of cool language hackery. :o)

cbetz• 18 years ago

A programming language should be simple to understand. C was simple. Adding classes/inheritance to C was not such a bad idea either. However, everything else in C++ just makes it massively complicated and a general pain in the neck to work with. In my opinion, all the crazies who insist on managing their own memory in the year 2008 should consider D (GC'd by default, but you can mess with the GC and use free()/malloc() if you want) [another poster already mentioned this]

If you are not aware of the reasons C++ sucks, check out the C++ FQA (frequently questioned answers):

http://yosefk.com/c++fqa/picture.html

Finally, I completely agree with others who say: Adding more and more features to a language DOES NOT make it easier to use.

andrewf• 18 years ago

The FQA is delightful snark. Thanks for that.

DaniFong• 18 years ago

A deeply skeptical look would focus on deep issues. This seems to focus on superficial issues...

jimbokun• 18 years ago

I'd like to suggest Common Lisp as a language that did a much better job of piling a ton of features into one language.

http://abhishek.geek.nz/docs/features-of-common-lisp

One simple example: Common Lisp is multi-paradigm, but has a soft spot for functional programming. So Common Lisp's Object System (CLOS), is implemented around generic functions and multiple dispatch. And generic functions are just as first class as any other function (I think, can anyone confirm this?).

Another example: supporting type declarations as hints to the compiler, but not mandating their use. This greatly reduces the "cognitive load" of this feature until you really need it.

uuilly2• 18 years ago

C++ is constantly pushing frontiers and if you're on the bleeding edge, it can be jarring. I just read responses similar to these on Slashdot about the latest release of the boost libraries. Boost is undoubtedly a spicy meatball, but there are some really simple things it does that make my life much easier. boost::shared_ptr and boost::bind alone make C++ a much better language. So why the hate?

Likewise when I see the new features in C++ I take what I can immediately understand and slowly grow into the things I don't. For example the 'auto' feature as really awesome and simple. It alone will save me many lines of code tedious code (and many more avoiding said tedious code.)

I guess I can just be happy knowing that I'll never be fluent in C++. I'll probably never understand how: http://www.boost.org/doc/libs/1_35_0/boost/bind.hpp works. But it doesn't mean I can't use it. Maybe one day I'll get into template meta-programming or maybe I'll forever gape like a tourist at the wonders the library creators bring forth.

The good thing about all these features is you don't have to use them all at once, and for situations where you want to evolve, there's always room ahead. I think for some language zealots, the expanse of the C++ frontier is somehow threatening. It's a bit like saying, I don't understand calculus so I won't use multiplication.

cousin_it• 18 years ago

But I do understand calculus. I have no problems using lambdas or binding arguments in many other languages. Only C++ manages to make it so baroque.

uuilly2• 18 years ago

You're right. But once you get used to it, it's not so bad. Also I'm not sure there is another language with all these features + speed.

I do rendering engines so I really don't have a choice.

signa11• 18 years ago

for a different perspective: http://www.devx.com/SpecialReports/Article/38813/1954?pf=tru...

A Deeply Skeptical Look at C++0x

Related Stories