On Fri, Aug 14, 2009 at 12:46 PM, Stefan Strasser <strasser@uni-bremen.de>wrote:
Am Friday 14 August 2009 00:24:54 schrieb Mathias Gaunard:
the vector operates on the stack as long as there is enough space, and moves to the heap afterwards. in most cases there is no dynamic allocation.
An implementation is free to consider any instance of an allocator with the same arguments passed to the constructor as equal, IIRC.
Does your allocator suffer from this issue?
I don't think so. the allocator doesn't have any state except a constant pointer to "buffer"(see exmaple above),
The pointer constitutes state.
so multiple copies of the same allocator can be used simultaniously.
Yes, but a default-constructed stack_allocator<> doesn't have storage so it cannot allocate.
the only c++ standard requirement it can't fulfil is a default constructor. I'm not sure why that is needed though. but the standard says that Allocator() must be a valid expression.
Also, is the container still copyable properly?
yes. the only issue that might arise is that the buffer on the stack could go out of scope before the vector has, as a result of swap()ing the contents of the vector into another vector with a longer lifetime. but I don't think that's a violation of the standard because that is also true for other allocators, e.g. pool allocators.
Am Friday 14 August 2009 00:00:37 schrieb Christian Schladetsch:
Two immediate issues are alignment and the fact that you are using a stateful allocator.
do you consider a constant pointer "stateful", and why is that a problem?
Yes, a pointer is state, and yes it is a problem. STL compliant allocators cannot have meaningful state. You may wish to search the boost list for the thread on 'Monotonic Allocator' to witness this being beaten into me over a period of days. The only way to do this is to use containers that respect stateful allocators. It's something I've been arguing for for a while, and these have now come via Boost.Interprocess.Container, to the proposed Boost.Container library from Ion. So your proposed stack_allocator<> could possibly work, if you used Ion's containers. But it is still not general. What you propose is a subset of a more general allocation model described here http://tinyurl.com/kkr7af. But you are right about performance http://tinyurl.com/l7k2op. Regards, Christian