Re: [boost] Interest in StaticVector - fixed capacity vector

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Andrew Hundt (athundt_at_[hidden])
Date: 2011-10-10 19:04:36

After looking through AutoBuffer carefully, I have determined that while
StaticVector and AutoBuffer are similar, each has different goals:
*
StaticVector goal:*
  A subset of std::vector that closely matches Boost.Array with additional
size tracking, with a fixed capacity defined at compile time.

*AutoBuffer goal:*
  A superset of std::vector with a higher performance stack based buffer
that falls back on dynamic allocation when that stack is exhausted.

I have found several cases where AutoBuffer fails to meet the goals tackled
by StaticVector:

1) Memory Size - AutoBuffer cannot handle large 64 bit sizes right now,
although this simple to fix.

2) Object Size - AutoBuffer stores a size, capacity, and a pointer to itself
(or an allocated buffer) making the object size significantly greater for
small buffers. In the smallest reasonable case of an AutoBuffer containing 2
chars, the size would be around 19 bytes, compared to around 3 bytes for
StaticVector. However, I may be counting incorrectly depending on factors
such as alignment.

3) Performance - I expect StaticVector to be at least slightly faster. This
is because StaticVector does not have to determine if data is on the stack
or the heap, and there is one fewer pointer dereference.

4) Allocation -  I personally have a specific requirement where I have to
place objects in exactly the right location in memory to work with a legacy
interprocess allocator. This makes the Allocators currently in AutoBuffer an
unacceptable option. I could meet this goal using AutoBuffer with an
allocator that simply throws an exception (bad_alloc?) or returns an error
any time an allocation is attempted, but why have this overhead when it
isn't necessary?

StaticVector has clear limitations due to its fixed capacity. However,
StaticVector seems to target a specific set of goals that are exclusive to
the current implementation of AutoBuffer. While some goals can be worked
around within AutoBuffer, others cannot because the end goal of AutoBuffer
differs from the end goal of StaticVector. Does this seem like a fair
assessment?

*
*
Cheers!
Andrew Hundt

On Mon, Oct 10, 2011 at 4:53 PM, Andrew Hundt <athundt_at_[hidden]> wrote:

> > I believe there is interest -- in fact, there's already such a library in
>> > the review queue. It's Thorsten Ottosen's AutoBuffer library.
>> >
>>
>>
> It appears there is only malloc allocation available in AutoBuffer now, not
> the in-object allocation I use. While I'm trying to maintain the simplicity
> of boost.array with size tracking, that may not be others' goal. I would be
> happy to try adding the allocation style of StaticVector as an additional
> allocator in AutoBuffer. Unfortunately, I am not sure how I could add the
> functionality I'm looking for to AutoBuffer myself. Is there a resource I
> could use to learn what I need to allocate the memory block inside the
> AutoBuffer object itself without pointers to externally allocated memory? It
> would be greatly appreciated.
>
>
>> I had thought that was slightly different.  I may be misremembering, but I
>> had thought StaticVector has a statically-determined maximum size, while
>> AutoBuffer is something like a variant< StaticVector, std::vector >...
>
>
> I happen to be using it in an embedded environment myself, but I can use
> exceptions. Is there some good example code somewhere that I can use as a
> style guide for implementing a no exceptions option?
>
> Cheers!
> Andrew Hundt
>