Re: [boost] Re: Query of Interest - vlarray

From: David White (dave_at_[hidden])
Date: 2002-04-17 04:38:41

On Wed, 2002-04-17 at 18:45, Itay wrote:
> 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.

This would be somewhat problematic. Potentially, there could be a
mechanism for having a different "stack" for each thread. Suggestions on
how this could be achieved are welcome :)

> 
> 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.

Yes, that's what would happen; sorry, I forgot to mention this. Also,
users wouldn't be able to create static vlarray objects, but I'm not
sure if this can be enforced by the compiler. Functions called when
initializing (or destroying) static objects may also be problematic.

David.

> 
> 
> -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
> >
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost