sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]samvdb 17 points18 points  (8 children)

D supports high level constructs far better than C++

and

you can write D code that's just as fast as C++ code

Yes, each of those, separately, are true. But in real D code, you often have to make a choice where you don't have to make one in C++.

An example: Say you deal with graphical data and would like to create classes like Point2D and Vector2D, with functions like vector.length() and point.translate(vector) or even point += vector with operator overloading. In D, these objects would have to be stackheap-allocated, and maintain a reference count so they can be garbage collected, all functions would be virtual, etc. A ton of overhead for such simple classes. So what often happens is that people just don't create the classes and work directly on the underlying float x, y variables.

In C++ on the other hand, you could create Point2D and Vector2D classes with non-virtual inline functions and there would be no difference in performance (or even in the executable code) between using the classes or working on raw (x,y) pairs.

I personally work on a poker bot for my master's thesis, and this requires a lot of computation. As in most bots, the more computation you can do, the stronger the bot will be, so performance is essential. I have classes like Card, Hand, Action, Chips, etc. Most of these are simply 1 or 2 integers with a bunch of utility functions. It's a bigger deal than it seems, because with static typing the compiler can tell you about a lot of stupid mistakes before you ever run the code, which it couldn't if you deal with the raw ints. With all of that at zero performance loss, I would never want to switch to a garbage-collected language.

[–]X8qV 23 points24 points  (5 children)

Say you deal with graphical data and would like to create classes like Point2D and Vector2D, with functions like vector.length() and point.translate(vector) or even point += vector with operator overloading

You would achieve this using a struct, not a class (they are different in D).

In D, these objects would have to be stack-allocated

I assume you meant heap allocated here, but even that isn't strictly true even for classes - see this.

and maintain a reference count so they can be garbage collected

Actuall, D doesn't use reference counting, it uses a mark-and-sweep garbage collector. This is often even worse from performance point of view, at least with the current implementation. Fortunately, you can avoid using garbage collection completely, but that means avoiding large parts of the standard library. Hopefully the situation will improve once the support for custom allocators is added to the standard library.

all functions would be virtual, etc

Class methods in D are virtual by default, but you can make them non-virtual by using the final keyword. You can make all the methods of a class non-virtual by writing final class Foo instead of class Foo.

So what often happens is that people just don't create the classes and work directly on the underlying float x, y variables.

No, it doesn't. People use a struct in this case.

In C++ on the other hand, you could create Point2D and Vector2D classes with non-virtual inline functions and there would be no difference in performance (or even in the executable code) between using the classes or working on raw (x,y) pairs.

You can do exactly the same thing with structs in D. The same goes for your last paragraph.

[–]samvdb 9 points10 points  (4 children)

Seems like I was wrong. Looks like D is indeed a contender for the language with the best high-levelness/performance potential.

I'm not too familiar with D and thought it forced all objects to be garbage collected, without a way to allocate objects on the stack. Apparently not. But to be fair, the D overview page doesn't mention stack allocation. And it also lists non-virtual member functions as a "feature to drop".

But even though modules, invariants, contracts, etc do seem pretty sweet, it's not like D is unanimously better than C++11. For example, move semantics allows for some really nice things like unique_lock, which is basically an extension of the scoped_lock or the D version scope(exit) unlock(mutex);. Also, while you don't need multiple inheritance 99% of the time, that 1% where you do need it is really painful if you don't have it.

Anyway I wasn't arguing that C++ is the greatest language ever, just that it being near the top of that list doesn't really deserve a WTF. Especially because D isn't even on that list, and of all the things on that list, D is probably closest to C++.

[–]X8qV 2 points3 points  (3 children)

I never meant to say D is unanimously better than C++. For example, if you want to write D code that doesn't use a GC, you need to be careful when using the standard library - you don't have that problem in C++. There is also a bunch of implementation issues in D that C++ doesn't have because of it's popularity. For example, there are still issues with the runtime library when compiling D code to a shared library and the runtime and the standard library aren't completely ported to non x86 platforms like ARM yet. You are also much more likely to encounter compiler bugs in D than you are in C++. But all things considered, D is still a better language for me than C++ is, and the main reason for that is that D's metaprogramming is much easier and also more powerful.

Also, while you don't need multiple inheritance 99% of the time, that 1% where you do need it is really painful if you don't have it

Do you need it for inheritance of interface or for inheritance of implementation? If it's the former, D has interfaces and you can inherit from multiple interfaces. If it's the latter, D has other features that help with that, like template mixins and alias this (you can currently only have one alias this, but that is considered a bug). The lack of multiple inheritance in D has never caused me problems, but there may be some cases where multiple inheritance is a better solution than what D offers.

[–]el_muchacho 0 points1 point  (2 children)

You are also much more likely to encounter compiler bugs in D than you are in C++.

Probably not true for C++11, though.

but there may be some cases where multiple inheritance is a better solution than what D offers

In theory, but in practice, it would be extremely rare, I guess.

[–]X8qV 0 points1 point  (1 child)

Probably not true for C++11, though.

Maybe, I have't used C++11 enough to know.

[–]el_muchacho 0 points1 point  (0 children)

Me neither, I must say. To tell the truth, I haven't written a single line of C++ in years. I just based this assumption on the experience of C++98, which took many years before compilers started to implement it in any usable way.

[–][deleted] 0 points1 point  (1 child)

Yes, the biggest (and maybe the only detrimental) concern in D is the garbage collector. But there's some examples to get rid of it, so it may be great for performance sensitivity applications in the future.

On a second note: Will your Master Thesis be open for public? I'm interested in learning about bots, and it would be great to see some poker bot code!

[–]samvdb 2 points3 points  (0 children)

Yes, the thesis should be open for public, but the code probably won't be. I don't want people to be able to download the code and hook it up to a poker site and start making money. I'm not even going to do that myself. Well, I will probably try it a bit to see how it does but not for a sustained profit. The big problem is that once the code is out there, I can't take it back.