On 15.12.2010 22:52, Steven Schveighoffer wrote:
On Wed, 15 Dec 2010 14:18:20 -0500, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
On 15.12.2010 3:50, Jonathan M Davis wrote:
On Tuesday, December 14, 2010 16:35:34 Craig Black wrote:
What say you?
I feel like the odd man out here since my perspective is so
different. I
use custom container classes even in C++, partly because I can
usually get
better performance that way, and because I can customize the the
container
however I like. So I will probably be doing my own containers
if/when I
use D.
Beyond that, my own personal preferences seem so different that I
hesitate
to mention them. I use dynamic arrays by far the most out of all
container
classes. I use them so much that I cringe at the thought of
allocating
them on the GC heap. My code is very high performance and I would
like to
keep it that way.
Also, my usage of arrays is such that most of them are empty, so it is
important to me that the empty arrays are stored efficiently.
Using my
custom container class, an empty array does not require a heap
allocation,
and only requires a single pointer to be allocated.
Not sure if these requirements are important to anyone else, but I
don't
mind making my own custom containers if I need to.
Dynamic arrays are already on the GC heap...
- Jonathan M Davis
Hm,
((T*)malloc(1024*T.sizeof))[0..size];
works. Just needs careful initialization of each field, since they
are filled with trash ...
And you can even do slicing. Just don't append to them and keep track
of the initial reference ;)
You can append them. The append code will recognize that it's not a
GC block and reallocate.
Good to know.
What you need to do more importantly is depending on the type of T,
you may need to register the block as a root in the GC. Otherwise, if
T contains GC references, those could be collected prematurely.
Right, this is very important! I just checked, and luckily I did this
only with plain data structs.
-Steve
--
Dmitry Olshansky