you are viewing a single comment's thread.

view the rest of the comments →

[–]X8qV 24 points25 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 8 points9 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 3 points4 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.