A Deeply Skeptical Look at C++0x(importantshock.wordpress.com)
importantshock.wordpress.com
A Deeply Skeptical Look at C++0x
http://importantshock.wordpress.com/2008/08/20/a-skeptics-look/
10 comments
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).
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).
" 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.
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.
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)
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.
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.
The last time around, the committee invented lots of features on the fly, many of which turned out to have far-reaching negative effects. (Think of the books that have been written on subjects like writing exception-safe code.) So I wouldn't lean too hard on "I know the committee thinks of backwards compatibility".
> 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.
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.
> 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.
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.
for (std::vector<int>::const_iterator i = vec.begin(); i != vec.end(); ++i)
for (auto i = vec.begin(); i != vec.end(); ++i)
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.
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;
auto func(int x) -> decltype(x);
decltype(x) func(int x);
The reason
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_.
decltype(x) func(int x);
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_.
> it uses x before its defined
Duh, noooo, really ? Have you ever wondered what magic causes this snippet to compile:
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:
Duh, noooo, really ? Have you ever wondered what magic causes this snippet to compile:
struct foo
{
foo() { bar = 1; }
int bar;
};
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>;
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...
In particular, the name collision problem does not happen with classes because each class is a new scope.
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...
In particular, the name collision problem does not happen with classes because each class is a new scope.
> 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.
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.
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.
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.
> 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.
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.
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,
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;
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.
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.
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.
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.
I do rendering engines so I really don't have a choice.
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.
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.
The FQA is delightful snark. Thanks for that.
A deeply skeptical look would focus on deep issues. This seems to focus on superficial issues...
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.
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.
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)
Addition of closures, on the other hand, will make C++ a viable back-end target for a lot of cool language hackery. :o)
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).
for a different perspective: http://www.devx.com/SpecialReports/Article/38813/1954?pf=tru...
The article makes quite a few good points. Then again, thats not very hard with C++.
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:
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.
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?)
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.
> 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.
I agree with many of your points, but I think that last bit is unnecessarily harsh.
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.
It can be quite hard actually... point(er) arithmetic is pretty complicated.
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/