

A Deeply Skeptical Look at C++0x - Anon84
http://importantshock.wordpress.com/2008/08/20/a-skeptics-look/

======
scott_s
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/>

~~~
ajross
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
_" 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.

------
nuclear_eclipse
> 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.

~~~
huhtenberg
> _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_s

      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.

~~~
huhtenberg
This certainly makes sense and it _is_ useful. But that's not the use of
_auto_ i was referring to. This one is:

    
    
      auto func(int x) -> double;
    

I realize that the above is allowed primarily for this case:

    
    
      auto func(int x) -> decltype(x);
    

but from a casual examination the following - simpler and cleaner - notation
can quite easily be made unambiguous:

    
    
      decltype(x) func(int x);
    

Also, isn't _typeof_ a more natural name for _decltype_ ? Again I realize that
the keyword overlaps with existing gcc extension, but semantics of latter is a
subset of C++0x one.

~~~
scott_s
The reason

    
    
      decltype(x) func(int x);
    

Is not used is that it uses x before its defined. Hence the new function
declaration syntax, where the return type is delayed until after the parameter
list.

I actually agree that _typeof_ is more natural, and I would prefer that
keyword. But one of the committee's goals is to not have new language feature
names clash with old conventions. Hence, the hashtable-based associative
containers will be called unordered_, and not hash_.

~~~
huhtenberg
> it uses x before its defined

Duh, noooo, really ? Have you ever wondered what magic causes this snippet to
compile:

    
    
      struct foo
      {
        foo() { bar = 1; }
        int bar;
      };
    

In other words, C++ is perfectly capable of handling forward references.
Parser can simply postpone evaluating decltype() expression until it reaches
the end of the function declaration. That's hardly a compiler "rocket
science".

I'm guessing that the real reason why they ended up with this ass-backward
syntax was to try and achieve some consistency between these two cases:

    
    
      auto <variable>;
      auto <function>;
    

Was it worth it ? IMO - hell, no.

~~~
scott_s
_Duh, noooo, really ?_

This isn't slashdot. Please be civil.

Read Section 5 for the rationale provided by the committee members who
proposed the syntax: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2004/n170...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2004/n1705.pdf)

In particular, the name collision problem does not happen with classes because
each class is a new scope.

~~~
huhtenberg
> _This isn't slashdot. Please be civil._

Take it easy. You don't appear to have a good understanding of the compiler
guts. What you said above was quite clueless, hence the reaction.

Also, slashdot as a metric of incivility - that's bold :)

> Read Section 5 for the rationale ..

I read the whole thing before I first posted in this thread. Since they are
extending function declarations with a new construct, nothing precludes them
from creating a scope for it. In other words, declspec() arguments should have
a scope of a function declaration they appear in. Their claims that this also
complicates parsing is just a speculation, and not too convincing one.

~~~
scott_s
I find it strange to say it's clueless when it's, in fact, the rationale used
by the committee members. I don't appreciate being mocked when I'm trying to
have a discussion. Compilers also happen to be part of my work, but that's
beside the point.

Introducing a new scope would, I think, introduce more corner cases than the
ugliness of the new syntax. (And I do agree that it's ugly in the context of
C++ which already has a function syntax.) Right now, scopes are only
introduced inside namespaces, classes/structs, functions, and explicit braces.
Having a new scope start _before_ a function and its parameters are declared
is counter-intuitive to me.

Now, I might actually be willing to take counter-intuitive semantics to avoid
the syntactic ugliness, but that's not my point. The point I've been trying to
make is that the committee has considered these issues; they didn't blindly
make a bunch of decrees.

~~~
huhtenberg
> _when I'm trying to have a discussion_

Your first response rebutted the point that I didn't make. Your second
response was stating trivial stuff that was obvious to the point of not being
even worth mentioning. So, yeah, I was also trying to have a discussion and go
over finer points of the alternatives and why they used the least attractive
one, but it didn't quite work.

> _Right now, scopes are only introduced inside namespaces, classes/structs,
> functions, and explicit braces._

You forgot _for_ loops. Their scoping is virtually identical to a function
declaration scope if latter were to be used.

> _The point I've been trying to make is that the committee has considered
> these issues; they didn't blindly make a bunch of decrees._

You have to realize that not all decisions made by the committee are based on
a technical merit. There is quite a bit of politics and ego involved. Whatever
they converge on might be a result that everyone is equally _unhappy_ with
rather than the opposite. Taking their decisions as written in stone makes
very little sense .. unless, of course, they come directly from Bjarne :)

A well-known anecdote is a history of standardizing IPsec suite of protocols -
a showcase for ego clashing. It took over two years to converge to something
that the majority of a workgroup agreed with. It was a compromise on top of a
compromise and the result was one of the most ambiguous and awkwardly written
set of RFCs.

------
uuilly
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
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.

~~~
uuilly
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.

------
cbetz
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
The FQA is delightful snark. Thanks for that.

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

------
jimbokun
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.

------
jimdesu
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)

------
jey
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).

------
signa11
for a different perspective:
[http://www.devx.com/SpecialReports/Article/38813/1954?pf=tru...](http://www.devx.com/SpecialReports/Article/38813/1954?pf=true)

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

~~~
orib
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
> 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.

~~~
orib
Perhaps. I was giving my first impression, but I strongly get the feeling that
the author didn't really try using C++ for any real project, and had already
decided against it long before he ever did anything with it.

