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?