Looking for documentation of D's lower-level aspects.

Sean Silva chisophugis at gmail.com
Sun Oct 23 18:57:19 PDT 2011


== Quote from Dmitry Olshansky (dmitry.olsh at gmail.com)'s article
> Less efficient is a moot point.
> When you do iteration and other stuff you'd use range, like you'd
use
> iterators in c++. Range gets stack/register allocated pointers
directly
> to data (or close to it, that depends on container) so the only
extra
> cost in reference type compared to value is the first indirect
access to
> construct range and it's negligible.

The problem isn't the speed of iteration, it's the extra heap traffic
that is involved. I mean, for you average app this isn't going to
matter; those are the apps that can just as easily be written in
Java/C#. But it can be a problem for serious systems code (the kind
that is pretty much always written in C/C++).

For example, if you look in the LLVM source tree, you'll see that they
bend over backwards to avoid heap allocations. For example, in some
cases, std::vector causes too much heap traffic so they have
SmallVector which preallocates a certain amount of storage *inside* of
the object itself in order to avoid heap traffic if the number of
elements doesn't exceed some predetermined amount. Even still, LLVM
uses std::vector all over the place, and it I've never seen a
std::vector embedded in a class by reference; it is always held by
value precisely because then you don't do an unnecessary heap
allocation.

I'm positive that if std::vector involved a heap allocation for the
vector object itself, llvm would basically have rewritten a heap-less
vector object, just like they have done in the more extreme case for
SmallVector. But the thing is that in D, it is possible to write an
easy-to-use vector for which it is a one-liner to switch between GC
heap-allocated vector object, by-value vector, preallocated internal
vector (like SmallVector), and beyond!

I admit, I'm very biased because my use case for D is low-level
systems programming a la C/C++, so naturally I want a standard library
that will not compromise on aspects that are important for the kinds
of programs that I write. Nonetheless, if the goal is to have "good
enough" containers, then it doesn't matter, but if the goal is to have
"truly optimal" containers (as I think it should be; D is certainly
powerful enough to pull it off elegantly), then it does matter.


More information about the Digitalmars-d-learn mailing list