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

"Paul Mensonides" wrote

Peter Dimov wrote

...

Andy Little wrote:

...

What is the problem with the result of plus being int_ ?

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_' (e.g.) then say 'int_::value>'

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