El 14/10/2011 1:08, Andrew Hundt escribió:
2011/10/13 Ion Gaztañaga<igaztanaga@gmail.com>:
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