Boost logo

Boost :

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.


"David White" <dave_at_[hidden]> wrote in message
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at