Gregory Colvin <[EMAIL PROTECTED]> writes: ...Dave:I think I would rather see a MPL lambda expression or metafunction class interface for allocator type parameters. It makes little sense for the allocator's user to be choosing its value_type.
Something like:
some_allocator<_1>
or
struct select_allocator { template <class T> struct apply { typedef some_allocator<T> type; }; };
with some_allocator's interface being like what's required for
std::allocator but not including misplaced interface bits such as
address/construct/destroy, and possibly max_size -- these can be added
by a std::allocator facade wrapper if neccessary.
I'm not sure we need a simple version and a complicated version.
I'm not clear how you intend the above to be used, or what you intend it to be a replacement for.
I intend it to be the sort of type parameter that gets passed to our objects which need custom allocation in place of a standard allocator. It's ridiculous, IMO, to pass allocator<T> to a node-based container which is *never* going to allocate a T object.
But given rebind() it doesn't really matter. We could just as well have specified that all containers take allocator<void> arguments.
The container itself should decide which type the allocator template gets instantiated on, via:
mpl::apply<mpl::lambda<S>, Node>::type
[ this is approximately the same as:
S::template apply<U>::type == some_allocator<U>
except that it works when S is the lambda expression some_allocator<_1> as well as when it's the select_allocator metafunction class below it. ]
Sorry, but I'm still not following this, but that may be because I don't know much MPL, so I can only guess at what you are up to. I probably need a detailed example of how to write and use one of these thingys to make any sense of your proposal.
Does your proposal support stateful allocators?
What the rebind requirement in the allocator means for pool allocation, for example, is that a pool_allocator<T> object must either be stateless (in which case allocator inequality is meaningless)
Yes, all stateless allocators compare equal, and stateless allocators are the easiest kind to make compare equal, as the standard currently requires allocators to do.
or effectively be able to allocate blocks of *any* size and alignment, rather than just as appropriate for T.
Yes, because node-based containers need to allocate nodes, perhaps of various kinds, but they don't expose their node types in their interface. So you have to pass in something, and we went with T rather than void or whatever.
It might have been better to have different allocator interfaces for array-based versus node-based containers, since array-based containers have no need of rebind(), and node-based containers have no need of allocator<T>.
It's a conceptual mess.
Alex didn't have MPL when he invented allocators. So they are messier than they need to be, but I still say they are not so bad as you claim, and that it would be easier for the next standard to repair them than to replace them.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
