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-14 11:06:30

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

I'm not sure that changing the policy will eliminate mistakes. I bet
that any time unchecked is selected so that push_back is not checked,
a fair number of programmers and others who are unfamiliar,
particularly those doing maintenance, will probably still make that
mistake.

Actually, I think the only way to genuinely avoid that mistake as much
as possible would be to have push_back always be checked, and also
have unchecked_push_back/insert.unchecked_push_back?

I know I'm arguing with own thoughts from yesterday. However,
selecting the 'right design' for this container does mean it has to be
considered both on its own, and in terms of what the other containers
do, because that is how people will expect this one to work.

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

I'm always a fan of reusing a lot of code. Is it possible to provide
different member functions based on different policies? Specifically,
a fixed size vector definitely requires a full() function. If not, how
to share the code between these implementations may require some extra
thought.

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

Any idea what the size overhead would be, typically?

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

Thanks for the clarification.

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

Is there a reference or something that explains the various costs in
terms of such as object size and code execution of policy based
design? I've used it, but I need to read a bit more to make sure I
have the complete picture.

Side note:
 Can anyone think of a better name than unchecked_push_back?