On the richness of C++

[Kevin Bealer]

Georg Wrede Wrote:

> I read
> 
> http://www.nwcpp.org/Downloads/2007/redcode_-_updated.pdf
> 
> and upon reading it I got thinking of something else. Those familiar 
> with C++ (aren't we all?) probably sometimes come across things that 
> somebody has done in C++ that are simply stunning. Things that one would 
> have thought would need a new language, or maybe just be impossible to 
> implement at all. I know I have. (A lot of Boost stuff is like that, 
> originally the STL got me breathless, but there's a lot that's not 
> template related, too.)
> 
> Is it just paranoia, or is C++ still more flexible and expressive than D?
> 
> Are there still things you can do in C++ that are impossible or too 
> awkward to do in D?
> 
> Of course, I don't mean Obfuscated C(++). While that definitely 
> demonstrates the unfathomable agility of the language, I'm only talking 
> about serious, non-juvenile stuff.

Sometimes.  If you want to wrap a small type like int or char in a structure
and do really advanced class-based stuff, I think C++ lets you do this and
keep both maximum efficiently and maximum flexibility, whereas in D, you
need to pick either a class or a struct, and some capabilities drop out with
the struct types.  In C++ you can inherit a bunch of small (e.g. 4 byte)
objects from each other and use template specialization to do compile
time "dispatches" on the inheritance hierarchy and so on.  D can do some
of this but its hard to do it the same way.

If you want to do really specific things with memory, C++ lets you do this, but
in D classes can only be handled by their object references.  You can't do a
"placement new" or anything like it with D classes.  In C++ you could build
classes that automatically allocate themself in a shared memory segment, but
in D, probably not.  Note that in practice, this is hard to do right and I think is
rarely used for much.

But I think D's advantages far outweigh these kinds of issues for almost all real
programming, and some things that are "in the pipe" like struct constructors or
destructors (which one was it?) will provide some of the missing functionality. 

Another thing, though ...

I was amazed that Boost could do things like the Lambda support with _1 _2, etc.
Those Boost guys are geniuses.  But it worries me that when first seeing it done,
I can't even guess how it is possible.  It also breaks down in a dozen ways -- if
the expressions aren't written exactly right, the wrong things happen at compile
versus runtime, binding doesn't happen right, etc.   It's hard to know, until the
code is running, whether it is doing anything like what you meant it to.  It's sort
of like a lawnmower that runs on dynamite.

Programming is like a chess game -- how much you can accomplish is dependant
on how many moves you can see ahead.  The C++ syntax to do metaprogramming
is very obscure -- this is why people didn't know it existed until after templates
were invented.  The fact that lambdas are possible is cool.  The fact that the space
of possible techniques is so opaque is less cool... in C++ you don't know if a thing
is possible nearly as easily as in a language like D where the path is better marked,
and where there are explicit syntaxes for these things.

For example, in C++ I was trying to write a static assert, but there are several ways
to do it and some of the syntaxes that used to work (arrays with 0 or even negative
size) no longer counted as errors.  It took a good hour working out what fails and
works in what contexts.  And I still only know the answer for one compiler.  (I think
there's a better version in Imperfect C++ for those interested).

In D, the syntax is simpler, and more direct, and more explicit, so you don't need
to be a chess master (as often) to figure out whether you can even get from point
A to point B, or how to get there, (or why it won't compile...)

Kevin