[boost] [MPL][pqs] best way to implement dimensional analysis

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-04 14:57:32

"Andy Little" <andy_at_[hidden]> writes:

> "Pedro Lamarão" wrote
>
>> I would like to see some "motivating example", like this one from the
>> MPL documentation:
>>
>> http://www.boost.org/libs/mpl/doc/tutorial/tutorial-metafunctions.html
>
> If the above is a motivating example for mpl

It's not meant to be, really.  It's designed to get the reader
acquainted with the library's fundamental abstractions.

> then I dont think it is the best one.

It's true, but not for the reasons you suggest.  The problem is that
in this example there is no code generation, only typechecking, which
makes it not a very good representative of what metaprogramming can
do.

> The problem is that mpl doesnt work as the (naive?) user expects,
> but worse the actual type of the quantity resulting from a
> multiplication isnt exactly defined. All that is known about it is
> that its dimension is comprised of "some sequence". 

True.

> In practise I found this, which was described as a convenience
> feature

Excuse me?  Where did you _ever_ see this described as a convenience?!

> actually caused a great deal more work in the implementation. It
> also causes problems with trying to figure what to register with
> Boost.Typeof and I suspect that it would continue to throw up
> similar problems whenever the type is required to be known. The fact
> is that an interface must have exactly predictable types. 

No, that is not a fact.  You can find numerous examples in the
standard (and more in TR1) where types are left unspecified.

> The interface in this case ( The visible part. e.g for use in
> function signatures etc) is in the template signature of the
> class. IMO mpl isnt the best way to implement the dimension of a
> quantity for this reason.

If you mean that using mpl::transform on the builtin MPL sequences
isn't the best approach, I'm inclined to agree.  It's a somewhat naive
approach designed to demonstrate some of the fundamental concepts in
the library.  I wouldn't agree if you were to suggest that MPL can't
be useful anywhere in implementing such a library.

> I am sorry to go on about this, 

Well, it is rather a strange outburst to find in the middle of the
Fusion review thread, where someone just referred to the MPL doc to
make a point.  Maybe you should bring it up separately if you want to
talk about this.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com