[phobos] Array preallocate function

[Andrei Alexandrescu]

I very much dislike the idiom with allocating a large array (and 
initializing its contents!), to then set its length to zero. It's 
completely assuming, and indeed the best proof is that that assumption 
is now invalid.

I think we could define a preAlloc() pseudo-method for arrays. Maybe we 
go as far as defining a @property capacity that can be read and written.

The best place is something that gets automatically included, like 
object.di. Then we can could on .capacity being as good as built-in.


Andrei

Steve Schveighoffer wrote:
> Now that the append patch is pretty much a lock in for the next version of phobos/druntime, we need to address losing preallocate functionality.
> 
> Specifically, the following code does not preallocate as it previously did:
> 
> auto buffer = new int[10000];
> buffer.length = 0;
> 
> buffer will reallocate on the first append because this can be considered a case of stomping, thereby wasting the first allocation completely.
> 
> Therefore, we need a way to implement this behavior.  I think the best way to do it is a druntime function (also TBD is where it goes!) which needs to call a function in the low-level rt/lifetime.d module.  Here is a strawman to discuss, anyone has a better idea, please present it.  I have no emotional attachment to anything here:
> 
> T[] preAlloc(T)(size_t nElements);
> 
> as for a module for it to belong in, currently druntime has the following public modules:
> bitop.d
> cpuid.d
> exception.d
> memory.d
> runtime.d
> thread.d
> vararg.d
> 
> And of course, there's object.di
> 
> My first intuition is to use memory.d, but that contains only one public item -- the GC struct.  However, this function is currently not a GC function (it is purposely not because then it can be GC agnostic, but I'm open to discussion on this).  Therefore, it probably should be outside the GC struct.
> 
> The only other place that makes sense to me is object.di.  And of course, it could live in its own module, but that might be overkill.
> 
> -------------------------
> 
> A further feature is to "reuse" a buffer.  For example:
> 
> auto buffer = new int[10000];
> loop
> {
>    buffer.length = 0;
>    // use append as necessary
> }
> 
> Should we implement this as a function or should we refer users to the Appender in std.array (does it support this feature)?  With preallocation, we can guarantee no stomping, but with reusing a buffer, we cannot because we rely on the user to ensure nothing else has references to data in the buffer.
> 
> My intuition is that we should not supply this function, and refer users to the Appender struct (and ensuring it can do this).
> 
> -Steve
> 
> 
> 
>       
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos