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

Reply via email to