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

From: Andy Little (andy_at_[hidden])
Date: 2006-02-24 18:00:31

"Paul Mensonides" wrote
> Peter Dimov wrote
>> 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

Thats a practical problem, but shouldnt stop discussion of the design I hope!

> and the result would most likely be a lot slower.

That is pure speculation(see below)!

> Dave was referring to the sequence identity problem because it is exactly the
> same kind of thing.

I dont think it is, but the design of the primitives affects more or less the
design of the sequences. The primitives are the building blocks.

> 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).

I can only go from my experience in pqs where exactly the opposite has happened.
After my mpl experience which resulted in an unusable library I redesigned the
library around compile- time meta-constants which can be equality compared using
is_same. This has dramatically speeded compilation compared with use of mpl (e.g
30 secs to 4 sec for a typical compile) And has solved the previous situation
where VC7.1 compiler gave an out of keys message on relatively trivial test
cases.

Bear in mind what use of boost::is_same over boost::mpl::equal_to implies. It
must mean that for a given comparative set the same or less types must be 
instantiated. That
cant increase compile times. Further in the case where different types compare
equal then  as more complex types are built out of the primitives, then there is
an O(N^N)  explosion of types all representing the same thing. This is I believe
what happened in pqs.

> 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>'

I believe it is a case of more complexity in the primitives resulting in greater
simplicity overall.

regards
Andy Little