What does C++ do better than D? - StackOverflow.com

[Peter Alexander]

On 2/08/11 2:29 AM, Andrei Alexandrescu wrote:
> Overall I feel Peter's post on stackexchange did more bad than good (of
> course that doesn't mean he had the right; I'm just writing this under
> the hypothesis he meant well and he'd be interested ). Within the
> confines of the community, discussing such issues is welcome and
> healthy. Mentioning these to the outside blows the issues out of
> proportion and conveys the wrong message to someone coming anew to D.

It's interesting that you've brought up the issue of the message being 
sent out about D, because I feel it is exactly the opposite: it's far 
too positive. Everyone seems to only talk about all the cool features in 
D and seem to ignore all the issues that exist.

I first came to D precisely because I had heard about all the cool 
features: the nice template syntax, uniform function call syntax (what's 
happening with that btw?), CTFE etc.  Of course, as soon as I tried to 
use those features I found out that they existed only in the 
specification, not in the implementations. I quit using D shortly 
afterwards out of frustration that the language wasn't what was 
advertised to me. I only came back after seeing Tomasz' work (which 
turned out to be in D1, but it sparked my interest again).

It's hard to quantify whether my post has had a negative or positive 
impact on the language, but I believe honesty and openness are good 
things. People coming anew to D shouldn't be misled into thinking that 
it has no issues (as I was -- no one mentioned the implementation 
issues). I believe a disappointed user is much worse than missed user.


> Plus, C++'s type system is marred by issues, so the statement has
> correctness issues to start with. Const is a mix of storage type and
> type qualifier; even most experts have no idea about that, and the
> minority of experts who do know about the distinction have difficulty
> figuring which is in effect when. Type deduction with functions and
> const is essentially a collection of special cases. Pointer to member
> functions have a type, but it can't be named, spelled, or used.
> Functions taking char* still accept string literals (compilers
> increasingly override that, but the rule is in the standard for C's
> sake). There is no way to convert a void* to a pointer to function,
> meaning all dynamic loading facilities must operate outside the
> standard. There is no way to specify or figure out alignment. Slicing
> polymorphic objects is legit. And so on and so forth.

Now this is very interesting and a perfect example of the point I'm 
trying to make about implementations being more important than 
specifications.

You say there is no way to convert a void* to a function pointer inside 
the standard.

Who cares? It works in the implementations.

You say there's no way to specify or figure out alignment?

Yes there is: compiler extensions. Wrap them in a macro and you're good 
to go.

These problems with C++ that you've listed are imaginary problems that 
only exist in theory. In real world C++ they are solved problems.

Do you know what will happen once (for example) alignment is 
standardised? Nothing. People will keep their compiler specific macros 
because they'll probably need to support pre-C++0x implementations. 
Maybe they'll add some extra macro conditions to support C++0x compilers 
and in 10 years time maybe they'll drop support for old compilers.

It's funny that you argue that a bad language design last forever while 
a bad implementation is transitory. From what I can see, it appears to 
be the other way round. Just look at the Boost library. It still has 
code to handle compilers without partial specialisation support, and 
code to work around various other implementation specific behaviour. C++ 
(the language) is changing, but those bad implementations are still in 
use. How many websites still need to support IE6?

I hope this illuminates the point I am trying to make.