Re: [boost] Query of Interest - vlarray

From: David White (dave_at_[hidden])
Date: 2002-04-16 04:48:47

Perhaps I didn't explain myself well enough...

It is not possible to implement "stack manipulation" in Standard C++. My
idea is to provide a mechanism that works around this limitation.

vlarray instances would be placed on the stack, just like all automatic
variables. The memory controlled by vlarray instances would be allocated
using a specially designed allocator that exploits the automatic
variable lifetime rules of C++. This allocator will create a
"pseudo-stack" using the free store to allocate memory from, which
should be much faster than general-purpose allocators. This would still
be substantially slower than simply putting arrays on the stack of
course - but would still be much faster than a general purpose memory
allocation.

David.

On Tue, 2002-04-16 at 10:02, hicks wrote:
> Is it possible to implement stack manipulation in a platform independent manner using C++?
> (I presume you mean the program stack.)
> 
> Craig Hicks hicks_at_[hidden]
> 
> 
> You wrote :::
> Message: 5
> From: David White <dave_at_[hidden]>
> To: boost_at_[hidden]
> Date: 15 Apr 2002 22:13:13 +1000
> Subject: [boost] Query of Interest - vlarray
> Reply-To: boost_at_[hidden]
> 
> 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.
> 
>