Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2002-03-05 18:07:14

Good points. I'll look into making what is currently used as a
"workaround" into the primary mechanism.


On Fri, 1 Mar 2002, Jens Maurer wrote:
Jens.M> Jeremy Siek wrote:
Jens.M> >
Jens.M> > The change you suggest is in fact the current approach we use to work
Jens.M> > around VC++. As to whether that approach is simpler is not so clear to me.
Jens.M> > For example, the 2nd approach requires a nested class, which could be
Jens.M> > regarded as a complication. Overall, I'd classify this NAD ;)
Jens.M> > david.> struct list_with_allocatorS { template <class ValueType> struct apply {
Jens.M> > david.> typedef typename Alloc::template rebind<ValueType>::other Allocator;
Jens.M> > david.> typedef std::list<ValueType, Allocator> type;
Jens.M> > david.> }; };
Jens.M> Yes, I'm late at it, but I'd like to say I agree with David here.
Jens.M> Also in terms of the recent template metaprogramming discussion,
Jens.M> it appears to me that the nested class template is the way to
Jens.M> go for any situation where you'd have wanted template template
Jens.M> parameters but they were too limiting.
Jens.M> What David is proposing is to have a user-defined metafunction to
Jens.M> create the list type the user wants. Terminology-wise, this blends
Jens.M> nicely with whatever template metaprogramming aids we come up
Jens.M> with later. In my opinion, thinking about it this way
Jens.M> ("here's a function that produces some list type") is actually
Jens.M> easier and much more straightforward than thinking in terms of
Jens.M> partial specializations.
Jens.M> Also, there's no "global state" as with a (partial)
Jens.M> specialization in the boost namespace, and all the helper
Jens.M> types I need are indeed localized in the user's namespace.
Jens.M> Jens Maurer

 Jeremy Siek
 Ph.D. Student, Indiana Univ. B'ton email: jsiek_at_[hidden]
 C++ Booster ( office phone: (812) 855-3608

Boost list run by bdawes at, gregod at, cpdaniel at, john at