

What does C++ do better than D? - bdr
http://programmers.stackexchange.com/questions/97207/what-does-c-do-better-than-d

======
iam
Seems a bit like apples and oranges, no? If someone's going to use a language
with a GC, why not go and use a full blown VM powered language in the Java or
.NET ecosystem?

The advantage of C++ is knowing exactly what happens when, and being able to
tightly control the memory footprint. If that's not the requirement, I see no
reason to spend extra effort on the language's verbosity.

That being said, the only feature D seems to really have that C++ doesn't
(besides gc) is compile time reflection aka traits (granted, it's possible to
derive some of those like boost traits, but for others like virtual function
detection it's impossible without compiler support).

~~~
bad_user

         why not go and use a full blown VM
    

Because you may not need a full blown VM; also D allows for manual
deallocation of memory if you seek predictability, something that full-blown
VMs like the JVM or CLR cannot do.

C++ is still used for applications development a lot, in instances where
people recommend these full-blown VMs. And while companies/individuals are
naturally conservative, this also does say something about the viability of
Java/.NET for development of applications.

I would also add here that I've never seen a Java application that I liked, or
that .NET has a stigma attached so that many people won't touch it with a ten-
foot pole.

D is somewhere in the middle of Java and C. It is low level enough to provide
predictable behavior with little overhead, but it is also high-level enough to
be comfortable and does guard (somewhat) against shooting yourself in the
foot, in many cases in which C++ does not.

    
    
         the advantage of C++ is knowing exactly 
         what happens when
    

But you don't know exactly what happens and when in C++, this being one
criticism against it -- in some instances D even has more predictable
behavior.

    
    
         I see no reason to spend extra effort on the 
         language's verbosity.
    

It's not the language verbosity that's an issue with C++ ; it's more about
many constructs being hard to use and error-prone. D fixes some of that.

It's also about the C++ language being hard to parse, that only companies with
big budgets like Microsoft/Borland can produce usable IDEs. It's also so hard
to parse that you'll always find inconsistencies between compilers and this is
also why the world has standardized on only 2 compilers: GCC and Visual
Studio, while using anything else (while wanting to maintain compatibility) is
seriously asking for trouble.

Not that D has many compilers (it doesn't) but its syntax was specifically
designed to be easier to write tools for it.

------
swah
Wait, do you mean D1 or D2? That's the problem with D.

~~~
starwed
The poster specifies D2.

------
abcd_f
C++ is better for finding a paying job. There you have it, someone had to say
it :D

------
5hoom
The big thing C++ has over D is momentum. Lots of stuff out there in C++ land,
whereas the D ecosystem feels a bit sparse.

Also, D doesn't have an equivalent to the RAII/Smart pointer paradigm (being a
garbage collected language) so it might not be as good for realtime stuff
where a g/c pause is unacceptable. If anyone uses D for realtime/high
performance programming please chime in though ;)

~~~
bad_user
Look, people make comments about D without knowing a thing about it.

Of course D has RAII -- <http://www.d-programming-
language.org/memory.html#raii>

In D you can also do manual deallocation of memory, if predictability is what
you want, the difference being that D comes with a garbage-collector from the
start and encourages you to use it, which is a lot better than reference-
counted pointers or other hacks; but at the same time it is also possible to
use D without a GC.

------
freakinjoe
skip D, try Go-lang

~~~
Peaker
I don't like D, but Go-lang is no substitute for C or C++: It's a GC'd
language.

~~~
sambeau
Unless you are doing realtime embedded programming there is absolutely no
reason why Go isn't a good substitute for C & C++.

Having worked in a large games company writing realtime performance-heavy code
in C# I know that GC isn't the barrier you think it is - in fact quite the
opposite: most of the time it makes things faster, cleaner and safer.

Having a GC can give you _more_ control over how your garbage is freed – it
helps you put it off until you have time to do it (without writing your own
complex garbage collection routines like many C++ programmers do). In the rare
places you need a malloc/free you can easily write your own and manage your
own memory pools.

~~~
Peaker
I use C for very-soft real-time, and have very little memory management code
in practice.

I think you're misrepresenting the situation about control. With C, you can
(and indeed sometimes do) manage a list of things to "free later". You have
full control over when to free things.

I use GC'd languages too, plentifully, and agree that GC beats a lot of the
average manual memory managed code. People using C write a _lot_ of
unnecessary mallocs/frees. But I don't think GC would work well for the kind
of code I work on.

If I wanted a high-performance GC'd language, why would I use Go and not
Haskell?

~~~
sambeau
Fair point about Haskell. Horses for courses. I love the simplicity of Go.
Haskell's simplicity breaks for me around the point that I have to use a
Monad: _brain splosions_.

~~~
Peaker
A Monad is pretty simple.

    
    
      class Monad m where
        return :: a -> m a
        (>>=) :: m a -> (a -> m b) -> m b
    

and the left-neutral/right-neutral/associativity laws:

    
    
      x >>= return = x
      return x >>= f = f x
      x >>= (\v -> y v >>= z) = (x >>= \v -> y v) >>= z
    

Last law can be expressed more easily if you define:

    
    
      (f >=> g) x = f x >>= g
    

Then you can say:

    
    
      (f >=> g) >=> h  =  f >=> (g >=> h)
    

How complex is that?

~~~
sambeau
_splosions_

~~~
Peaker
That may be hard to figure out at first -- but if you figure that out: you're
pretty much done.

It's really _not that hard_.

