4 ms·

> 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

> 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 18y 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_s 18y 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.
  - huhtenberg 18y ago
    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 18y ago
      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 18y ago
        > 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 18y ago
        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/n1705.pdf 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.
        huhtenberg 18y ago
        > 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.
- fh 18y 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!

huhtenberg 18y 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_s 18y 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.
- huhtenberg 18y ago
  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 18y ago
    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 18y ago
      > 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 18y ago
        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/n1705.pdf 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.
        huhtenberg 18y ago
        > 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.
fh 18y 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!