std.container.RedBlackTree versus C++ std::set

[monarch_dodra]

On Thursday, 14 February 2013 at 10:23:18 UTC, Namespace wrote:
>> I agree. There are cases where structs make a lot of sense, 
>> usually when they are very simple simple and contain no 
>> pointers or references, otherwise structs should be avoided in 
>> favor of classes to avoid doing copy/move constructors and to 
>> avoid concerns over performance optimizations. With classes, 
>> only certain points in your code require that a duplicate copy 
>> be made of the class instance, the majority of code need only 
>> to pass around a reference which is the default behavior - 
>> easy and fast!
>>
>> --rt
>
> It sounds like Java philosophy: Objects are always better.
> Or have I misunderstood?
> In any case, a intensive use of classes / objects, instead of 
> structs would be also an enormous heap effort.
> I usually try to use as few classes as possible.

It's a matter of balance. If you start having really complex 
objects (and big, eg > 100 bytes), then classes tend to scale 
better.

If having a class is *really* too much overhead, but your objects 
start getting too big to pass around by value, you can just new 
them on the heap, and you'll get the "best" (or worst?) of both 
worlds.

Another good balance are stack based struct pointer wrappers to 
implementation : You can pass them by value, but they carry a 
complex payload. The advantage to doing this over a naked array 
is the static type. The *dis*-advantage is that D has no standard 
default initialization scheme (classes do though). Most things in 
phobos use this scheme.

The point I (we?) are trying to get across is that *usually* (not 
a hard rule) copying things in D is *expected* to be trivial and 
cheap. If this is not the case, then the tools you'll interface 
with will not work optimally.