D - more or less power than C++?

Walter Bright newshound at digitalmars.com
Sat Mar 4 10:29:15 PST 2006


"Kevin Bealer" <Kevin_member at pathlink.com> wrote in message 
news:dubrg5$111g$1 at digitaldaemon.com...
> I think it boils down to this - in C++ the lifetime of objects can be
> influenced by other objects, and as part of algorithms.  And
> algorithms and code can be influenced by the lifetime of objects.  In
> D the lifetime of objects is influenced by code, but not the other way
> around.
>
> Maybe this is just the cost of GC.  It seems like both methods could 
> coexist,
> but if enough features are added to D it will weigh as much as C++.  I'll 
> have
> to think about whether there are other cases that auto/on_scope can't do.

I've thought many times that a great deal of the complexity of C++ comes 
from overloaded assignment, copy ctors, etc. Every class you build 
essentially has to overload these. It winds up adding lots of bloat and 
obfuscation to every class. There's a reason why Java classes always look so 
simple, and C++ ones you have to wade through a lot of stuff just to figure 
out what the point of the class is.

> I guess what I'm saying is that in C++ you have incremental power over the
> functionality.  If you want a virtual table but no operators, you can have 
> it.
> Operators but no virtual table, okay.  Each feature is turned on 
> seperately.  In
> D there is struct, which has some stuff, and class, which has everything 
> and a
> very different personality.

Right. And the argument with C++ is that the incrementalism gives the max 
efficiency possible with each situation. That argument is theoretically 
correct, but in practice, I find it rarely works out that way.

> This is starting to sound like a complaint, but actually I like D's way. 
> All
> that syntax is why C++ is so treacherous for anyone who doesn't have a law
> degree in it.  The first ten times you write operator=(), you need to look 
> at
> the book.

Yes.

> But C++'s a-la carte is powerful, if you want to spend time crafting
> the classes.  It's a tradeoff.  D makes a lot of common sense tradeoffs. 
> In C++
> you can build uncopyable classes, inherit from classes that have no code 
> (i.e.
> traits programming) etc.  D tosses a lot of semi-obscure flexibility and 
> lets
> some of it in through other doors.  Again, good decision, but there are 
> small
> ramifications here and there.
>
> I'll just force myself to stop typing now. ;)

You're right, and that was a deliberate D design decision. And I'll add to 
that my opinion that all those "small ramifications" do not add up to much 
of anything in real programs. An illustration of that is DMDScript in C++ vs 
D. The D one is faster, even though the C++ was carefully tuned with all 
those small ramifications. They didn't amount to squat in the end because 
the C++ version turned out to be brittle as a result (i.e. resistant to 
change). The D version was much easier to modify to try out different 
approaches, which resulted in it being faster. 





More information about the Digitalmars-d mailing list