|
|
Re: Why? Language Archaeology ... and Metaprogramming
|
Posted: Jun 18, 2009 5:09 AM
|
|
> > C++ does not have flaws because of compatibility with
> C.
> > C++ has flaws because it was not thought out well.
>
> This is precisely what I'm arguing against. If you had
> been there as I was, you would have seen very smart people
> excruciatingly going over each decision, discovering all
> the problems before adding features. It was thought out
> *extremely* well, and the reason the language is difficult
> is precisely because of C compatibility.
>
> Oh. Wait. You're trolling, aren't you. You got me. Good
> for you.
No, I am not trolling at all. Having worked with C++ for the last 11 years, and having used every feature of the language, I know that there are alternatives that could have been chosen that could have made the language much better.
Some examples:
1) the distinction between classes and non-classes types. All types could have been classes, even primitives.
2) uninitialized variables. Variables should always have been initialized to their default value. If there was a performance issue, then the programmer should have a keyword in his disposal telling the compiler to allocate memory for the variable but not initialize it.
3) default values for parameters only at the end of the parameter list. A function could have default values in any of its parameters, not only in the parameters of the left side of the parameter list.
4) lack of pass-by-name parameters. Why C++ doesn't have it? there is nothing that has to do with C combatibility.
5) the choice of angle brackets for template parameters. This was a mistake that made the grammar a lot more ambiguous than what it was.
6) the choice of syntax '= 0' for abstract methods, because of fear of introducing another keyword. Nothing to do with compatibility with C.
7) lack of anonymous functions. They could be very simple, i.e. not be closures, not capture the environment. They could be localized parametrized pieces of code that refer to hardcoded addresses (so there is no need for the extra data pointer). Again, nothing to do with C compatibility.
8) lack of tail call optimization. Again, nothing to do with C compatibility.
9) lack of compile-time introspection of classes properties (class names, class members, class member types, class member names, etc). Again, nothing to do with C, but it would greatly simplify a lot of code.
10) initializer lists. They could have been part of the constructor code.
11) lack of static initialization of class members as a separate function. The same code must be repeated over and over in each constructor.
12) uniform construction syntax. Again, nothing to do with C. C(a) and C = a should have been equal. C++0x solves this with C{}.
There is a lot more of this stuff. The list of things that could have been better contain a lot of items.
So...obviously I am not trolling, as you say. C++ could have been much better right from the start. It is just that it was not thought out very well.
|
|
Previous Topic
