why allocators are not discussed here
Adam D. Ruppe
destructionator at gmail.com
Tue Jun 25 18:24:57 PDT 2013
I was just quickly skimming some criticism of C++ allocators,
since my thought here is similar to what they do. On one hand,
maybe D can do it right by tweaking C++'s design rather than
discarding it.
On the other hand, with all the C++ I've done, I have never
actually used STL allocators, which could say something about me
or could say something about them.
One thing I saw said making the differently allocated object a
different type sucks. ...but must it? The complaint there was "so
much for just doing a function that takes a std::string". But,
the way I'd want to do it in D is the function would take a
char[] instead, and our special allocated type provides that via
opSlice and/or alias this.
So you'd only have to worry about the different type if you
intend to take ownership of the container yourself. Which we
already kinda think about in D: if you store a char[], someone
else could overwrite it, so we prefer to store an
immutable(char)[] aka string. If you're given a char[] and want
to store it, you might idup. So I don't think doing a private
copy with some other allocation scheme is any more of a hassle.
(BTW immutable objects IMO should *always* be garbage collected,
because part of immutability is infinite lifetime. So we might
want to be careful with implicit conversions to immutable based
on allocation method, which I believe we can protect through
member functions.)
Anyway, bottom line is I don't think that criticism necessarily
applies to D. But there's surely many others and I'm more or less
a n00b re c++'s allocators so idk yet.
More information about the Digitalmars-d
mailing list