What does C++ do better than D?(programmers.stackexchange.com)
programmers.stackexchange.com
What does C++ do better than D?
http://programmers.stackexchange.com/questions/97207/what-does-c-do-better-than-d
5 comments
C++ is better for finding a paying job. There you have it, someone had to say it :D
skip D, try Go-lang
I don't like D, but Go-lang is no substitute for C or C++: It's a GC'd language.
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.
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.
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?
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?
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.
A Monad is pretty simple.
class Monad m where
return :: a -> m a
(>>=) :: m a -> (a -> m b) -> m b
x >>= return = x
return x >>= f = f x
x >>= (\v -> y v >>= z) = (x >>= \v -> y v) >>= z
(f >=> g) x = f x >>= g
(f >=> g) >=> h = f >=> (g >=> h)
[deleted]
I know effectively nothing about D, but one of the repeated answers was that D effectively requires you to use its GC. (With the qualifier that while technically, you don't have to use GC, doing otherwise will cause pain.)
You can switch the GC off in D you can't in Go. I however wouldn't advise it - GC has a valid reason to be the essential it is considered to be today.
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 ;)
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 ;)
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.
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.
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).
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).
why not go and use a full blown VM
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
I see no reason to spend extra effort on the
language's verbosity.
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.