[boost] Re: Query of Interest - vlarray

From: Itay (itay_maman_at_[hidden])
Date: 2002-04-17 03:45:22

There are two issues which should be handled, otherwise users of this
vlarray will likely run into all sorts of undefined behaviors:

1) Multithreading: The stack based allocator should be thread-aware to
prevent allocations from one thread to interleave with allocations from a
second one.

2) Heap allocation of vlarray objects should be prohibited. It seems like a
simple problem with a simple solution (having a private new/delete
operators) but there might be side-effects/portability-effects which I am
not thinking of.

-Itay

"David White" <dave_at_[hidden]> wrote in message
news:1018872794.1365.85.camel_at_blah...
> I was wondering if there would be any interest in a class template,
> vlarray, which would have functionality similar to a stack-based array,
> but which would have its size set at runtime. Essentially it would
> provide functionality similar to the Variable Length Arrays (VLAs) now
> offered in C. It would have a specialized allocation strategy written
> for it, which would provide allocation/deallocation times much faster
> than more general containers such as straight heap-based arrays or
> vectors.
>
> In order to allow this specialized allocation strategy to be
> sufficiently fast, instances of vlarray would only ever be permitted to
> be allocated as automatic (stack-based) variables. Thus, since they
> would allocate in their constructor, and deallocate in their destructor,
> all allocations and deallocations would take place in a
> Last-In-First-Out (LIFO) order, and thus the allocation strategy could
> be written with this as an assumption. In fact, the allocator would
> simply just use a stack-like data structure to allocate and deallocate
> from - this being much simpler and faster than strategies that
> general-purpose allocators must use.
>
> The interface would be almost identical to boost::array - except that
> the size of the array would be a parameter to the constructor instead of
> a template parameter, and some more constructors would be added.
>
> Considering the number of requests there are for addition of VLAs into
> C++ - or the standardization of the alloca function that some
> implementations offer, I feel that vlarray would be of use to many
> programmers who want these features because of their speed over normal
> heap-based allocation. I would be interested to know if others think
> that this idea has merit as an alternative to VLAs/alloca.
>
> Cheers,
>
> David.
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>