This is a good idea. I still think a function to do this should be available, so you can do the allocation in one step instead of declaring an array and then setting its capacity.
What about the issue of shrinking the allocated size as in the loop I showed? Should this be allowed via builtin arrays or reserved to a wrapper? -Steve ----- Original Message ---- > From: Andrei Alexandrescu <[email protected]> > To: Discuss the phobos library for D <[email protected]> > Sent: Fri, February 19, 2010 6:20:25 PM > Subject: Re: [phobos] Array preallocate function > > 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 > > href="mailto:[email protected]";>[email protected] > > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos > mailing list > href="mailto:[email protected]";>[email protected] > href="http://lists.puremagic.com/mailman/listinfo/phobos"; target=_blank > >http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
