On 9 Jun 2009, at 20:40, Ross Levine wrote:
Chris, it clearly states in your paper that you referenced, in section 4.1, that he is assuming the erasure of the equal-allocator assumption. Checking the C++ standard, section 20.1.6, you will quickly see that the equal-allocator assumption is still in place under the current standard. Thus the techniques mentioned in that paper are non-portable. I will be the first to say that this is stupid and makes lots of problems, but it is there and there's nothing we can do.
True, but that paper seriously breaks things anyway -- it adds more methods to allocator (via a versioning method) which must then be used by the containers to get any benefit. By the time you have required those non-standards things, it's probably not unreasonable to also require proper support for stateful allocators. Chris
Perhaps having a boost.config macro could solve the problem. If a particular implementation enforces the equal allocator assumption, a template specialization for std::vector<T, boost::monotonic_allocator<T> > (and list, deque, etc) could be defined.
On Tue, Jun 9, 2009 at 12:52 PM, Christopher Jefferson < chris@bubblescope.net> wrote:
On 9 Jun 2009, at 17:14, Christian Schladetsch wrote:
Hi Andrew:
Maybe yes, maybe no. My understanding of the allocators was that they were
originally used to abstract differences in pointer types like __far and __huge pointers. Their usage has become substantially more complex and varied since then.
If STL containers cannot be made by any means to use the stack for storage then we need a new set of containers.
Please, just slow down your posting slightly, and put some more thought in.
There is no issue with using stack storage for containers -- I do it regularly. The problem is that std::allocator doesn't work well in extremely memory-limited environments, due to:
a) lack of inline expansion b) inability to return maximum amount of memory available.
(a) and (b) actually mainly come from the fact that the C memory interfaces don't well support these things. (b) isn't really available, and while you would think realloc would support (a), it doesn't, as there is no way of telling realloc not to move if it can't extend. There have been attempts to correct this error at the C level, which would then hopefully permeate up to allocators.
This problem has been previously discussed and solved, on paper at least, see my earlier e-mail today which referenced:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html
Implementing this would solve your problems, so any competing suggestion should either build on, or improve, that plan.
As I already spent 20 minutes today looking at code you wrote, which you obviously never tested on any compiler, maybe now you could spend a while, read that paper, and see what you think about it.
Chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost