Re: [Boost-users] [mpl] newbie question

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-02-24 17:09:50

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Peter Dimov

> Andy Little wrote:
> 
> > What is the problem with the result  of  
> plus<int_<A>,int_<B>> being 
> > int_<A+B> ?
> 
> How does the specification of mpl::plus look like in your 
> proposed model?

I don't think *this* it is necessarily difficult to implement as Andy would
prefer.  However, global application (to the MPL) of the underlying concept
represents a major refactoring and the result would most likely be a lot slower.
Dave was referring to the sequence identity problem because it is exactly the
same kind of thing.

There is a dinstinction between types on which metaprogramming operates (such as
'int' or 'const MyClass') and the types of metaprogramming constructs
themselves.  The latter need only be structurally compatible with the concept
(i.e. the archtype or the Plutonic form of the structure).  If the MPL starts
making guarantees that metatypes (e.g. a 'vector', a 'list', an 'int_<A>') can
be used as a non-metatype, it will lead to either 1) a combinatorial explosion
of code or 2) a drastic efficiency hit (because the library will be explicitly
rewriting structures after they are built).

Granted, if this was done for integral wrappers only, the combinatorial
explosion wouldn't be too terribly bad.  IMO, you don't need wrappers for every
integral type in this domain, you only need an integer wrapper (around 'long'),
a natural wrapper (around 'unsigned long'), and a Boolean (around 'bool').
*But*, it still comes down to a more fundamental issue....  Should the library
endorse the use of the types of metaprogramming constructs themselves as
non-metatypes?  I'd say it shouldn't.  If you need that for 'int_<A+B>' (e.g.)
then say 'int_<plus<int_<A>, int_<B> >::value>'

Regards,
Paul Mensonides