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

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-10-14 07:03:44

El 14/10/2011 1:08, Andrew Hundt escribió:
> 2011/10/13 Ion Gaztañaga<igaztanaga_at_[hidden]>:
>> It's interesting but we need some consensus on several issues
>
> IMO, here are the most interesting and consensus worthy choices so far
>
>> If swap is O(N), should it be provided?
>
> Yes, I am fairly certain std::array provides a linear swap, and
> boost.array definitely provides it, so StaticVector should too.
>
>> unchecked functions?
>
> They should definitely be provided.

Anyway, IMHO comparing begin()-1 with push_back is not a good example 
for me. Programmers know front() has preconditions, but we currently 
have no push_back preconditions for push_back, insert, etc. and this can 
be a great source of mistakes. A solution could be selecting the 
behaviour by pseudo-allocator type options at compile time:

boost::container::vector
   < int
   , fixed_buffer<int, /*options*/throw_when_capacity_exceeded OR 
unchecked_capacity OR ... > >;

> Interesting. So this stack allocated pseudo-allocator would look and
> act (partially) like an allocator, but not fit the definition of one
> due to the C++03 and C++11 rules against them.

It's just to add and extend allocator concept and add support for it in 
boost::container::vector. It's a hack, but allows reusing a lot of code.

> Is this suggesting that boost::container::vector be directly modified
> to support both fixed capacity as well, or just mixing some of the
> shared code in?

It's an option.
>
>> There are more issues. Do we want to support some kind of StaticVector
>> compatible with shared memory? then we need to specify pointer and
>> const_pointer as those define the pointer type stored in iterators...
>>
>> Anyway, I think that we could implement an approach similar to Howard's
>> stack_alloc quite easily, and get most benefits with a bit of size overhead.
>
> so considering the other posts that internal storage allocators are
> forbidden, how would this work?

Those are forbidden by the standard, but a concrete implementation can 
support extensions, provided it still supports standard allocators. In 
this case boost::container::vector (and only this container) can change 
its behaviour when some specially marked (pseudo-)allocator is used.

> Well that may mark the end of my StaticVector work, but that is how
> these things go. At the very least there has been productive
> discussion. Although, perhaps the size overhead advantage of
> StaticVector would allow room for it considering to the difference it
> could make for embedded systems.

The pseudo-allocator way is just an idea, I don't know if we can find 
much more problems in the way.

Ion