Paralysis of analysis

[Steven Schveighoffer]

On Wed, 15 Dec 2010 14:18:20 -0500, Dmitry Olshansky  
<dmitry.olsh at 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.

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.

-Steve