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

"David Abrahams" wrote

"Andy Little" writes:

...

"Andy Little" wrote

...

The expectation ( based on OP's light reading of examples I guess ) is this

assert( boost::is_same < mpl::transform< vector_c ,vector_c ,some_plus_func > ::type , vector_c

...

::value == true);

Personally I think ( even ) that is with (some mods) a realistic expectation.

FWIW Enclosed is a small sample which seems to work ok in VC7.1 and gcc4.01, bearing in mind its based on expectations not status quo Formatting of output works best in vc7.1 BTW.

IOW Its not impossible to make it work.

<sigh> Nobody ever said it was impossible.

What you're doing here fails one of the primary design goals of the MPL: in the same way that the STL iterator abstraction avoids an MxN explosion of algorithm implementations (where M is the number of algorithms and N is the number of data structures), the MPL is designed to avoid the same kind of explosion. If you follow this path, you will end up reimplementing every algorithm once for every data structure.

Finally, even if you do meet the expectation, it will be incredibly fragile: it becomes impossible to extend the library (or user code) and continue to meet expectations. You add a new algorithm, and then suddenly the expectation is broken for any user-defined sequence types that you didn't know about. You add a new sequence, and the expectation is broken for any user-defined algorithms you didn't know about.

...

Might be useful as a relatively simple demo anyway. Could also be used to explain the reasons for rejecting this approach too of course ;-)

I hope you find my explanation above satisfactory.

I understand it. I concede that I was wrong to argue about it, so I'm sorry for wasting your and everyone elses time. Of course If anyone can implement the dimensional-analysis part of pqs ( in the Boost vault in The Physical Quantities Units directory) , such that it compiles faster than it does currently, by using mpl, then I will be happy to re-implement it using mpl. Otherwise I dont currently see the benefit. That may change of course if for some reason I need the mpl features you mention above, though currently the dimensional-analysis code seems quite stable. The only reason I can see might be to make the sequence of base-units modifiable in length, however my inclination would be to do this by means of a config macro . Anyway I shall be interested to see what Noel Belcourt comes up with. My feeling is that mpl is unlikely to beat the current set up in terms of compilation speed but I'd be happy to be proved wrong. It is of course a very unfair challenge because my code is customised for this one job , whereas mpl must be generic. regards Andy Little