dark mx
Posts: 7
Nickname: darkmx0z
Registered: Mar, 2008
|
|
Re: Why? Language Archaeology ... and Metaprogramming
|
Posted: Jun 20, 2009 2:09 PM
|
|
> > > 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.
you like to troll sometimes :) but I think this is not the case, your arguments were good
> Some examples:
>
> 1) the distinction between classes and non-classes types.
> All types could have been classes, even primitives.
Agree. Some minor changes could have been done here and there (for example, inheriting from a primitive is something I am sure most C++ programmers have wished at least once, yet we can't do it).
> 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.
This is purely C compatibility
> 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.
Agreed. Reusing default keyword could have worked.
f(1, default, 2);
Google doesn't like default parameters for good reasons, but given that we already have them, we could make them more useful.
> 4) lack of pass-by-name parameters. Why C++ doesn't have
> it? there is nothing that has to do with C combatibility.
This is discussed in Stroustrup's Design & Evolution of C++. Headers are the main problem (you are not forced to use the same name for parameters in a declaration and the definition, this could bring maintenance chaos).
> 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.
They look nice, but I agree with you.
> 6) the choice of syntax '= 0' for abstract methods,
> because of fear of introducing another keyword. Nothing to
> do with compatibility with C.
Irrelevant I think. Its ugly but simple enough.
> 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.
I think I agree.
> 8) lack of tail call optimization. Again, nothing to do
> with C compatibility.
Compilers are better here and any current problems are C's fault (calling scheme and varargs).
> 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.
Agreed but not Stroustrup's fault. Compilers back in 1970 were required to be fast and simple ones. When technology was permitting, a lot of work was already needed to finish the ISO C++98 specification and a lot of work is still being done for C++0x. Since this is obviously useful, I think this is more a matter of manpower and time.
> 10) initializer lists. They could have been part of the
> constructor code.
Completely agree.
> 11) lack of static initialization of class members as a
> separate function. The same code must be repeated over and
> over in each constructor.
Completely agree. Modules (unfortunately not ready for C++0x) will help here, so again its matter of manpower and time (which is sad anyway).
> 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{}.
I don't like C++0x's choice but I agree with everything else.
> There is a lot more of this stuff. The list of things that
> could have been better contain a lot of items.
Completely agree but Stroustrup couldn't predict the future. If he knew what he knows now, several things would be different. You can't hardly innovate without making mistakes (yet any resulting mistakes were analized before the decision was made and they were considered not to be mistakes back then, it was not that easy).
Bruce I loved your article. I hate when some programming language tries to sell itself as "NAME_HERE but done well". It reminds me of Gosling's blog entry "Java is now faster because the VM learned how to use alloca for optimizations which beats the pants of C's malloc!" Obviously Gosling never says "but C always uses alloca, malloc is explict and special-purpose and C doesn't need to allocate quarter a gigabyte upon the program's entry to be fast".
|
|
Previous Topic
