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

"Andy Little" writes:

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.

If you think so, then please provide a patch that satisfies that expectation. This is hard to accomplish in any reasonable amount of code. Your patch should also satisfy assert( boost::is_same < mpl::transform< list_c ,list_c ,some_plus_func > ::type , list_c >::value == true); (which is arguably even harder to do), just to prove that the expectation can be handled over a range of sequence types.

The above would make sense if vector_c was a standalone type rather than an *interface* to vector.

It would only make sense if it were reasonably implementable. The above isn't even true for vector. That is, assert( boost::is_same < mpl::transform< vector ,vector , _1 > ::type , vector >::value == true); will likely also fail. The actual resulting type is something like vector2 Totally apart from impelementation difficulty, there are some very simple constraints that absolutely force this expectation to break down in some cases. Consider push_back, int>::type list has a fixed number of template parameters (all with defaults). At some point there is no longer a way to represent the sequence with one more element as a specialization of list, and you're stuck.

The act of doing that would introduce complexities sure because it would be necessary to specify the semantics. To make the above work some_plus_func would presumably need to look like

template some_plus_func;

or

template some_plus_func;

No it would not. And that's for all practical purposes unimplementable within the framework of the MPL. If you want a library whose metafunctions can operate directly on integral constants, and where you pass templates instead of types to algorithms, you want a different library. See Loki, maybe.

I think its possible to specialise transform to pick this up.

No it isn't. The 3rd argument to transform is a type; you can never pass a template there, no matter how many specializations you write.

Instead of the type placeholders you would use arbitrary constants ( <0,0> )here:

assert( boost::is_same < mpl::transform< vector_c ,vector_c ,some_plus_func<0,0> > ::type , vector_c >::value == true);

Well, that's something different altogether than what you said before. Now you're passing a type again. But what you've written above not only causes a code explosion in the metaprogramming library, it's completely counter to the MPL aesthetic and philosophy. Maybe you want a different library.

Of course If vector_c was a standalone type then a function e.g 'to_vector' to convert to a mpl::vector would be required to get the current behaviour

assert(boost::is_same< mpl::to_vector< long_<1>,vector_c >::type, mpl::vector,long_<2>,long_<3>, long_<4> >

...

::value == true);

Anyway the point is I dont think its impossible to come up with an alternative design as you seem to be suggesting.

Stop. I never suggested it was impossible to come up with an alternative design. I have said, repeatedly, that meeting the expectation you're describing here in any way results in a vast expansion of the amount of code in the library, which would likely cause slowdowns in user code, and is very difficult to do at all, to say nothing of doing it well.

But (Maybe more realistically) the same issues crops up with mpl::int_

assert( boost::is_same < mpl::plus< int_<1>, int_<1> > ::type , int_<2> >::value == true);

Again I think thats a reasonable expectation, but it fails

That's a separate issue. It's far less hard to accomplish than what you described above.

But in both cases the mpl designers argument is that these are only interfaces, designed to save a bit of typing.

That's not an argument, it's a fact of the design intention.

My problem with this argument is that (as it stands) they are an input only interface and so when the type is regurgitated as error messages or when using comparisons etc one is presented with something "conceptually identical" as far as the designers are concerned but that has been the result of what seem to the user like arbitary transformations. Thats not pleasant. To the uninitiated it just looks like somethings gone wrong with the calculation.

So submit a patch that fixes it. Surely you could have done so by now, more easily than all of this posting. That would at least prove your point that it's achievable.

In case of int_, long_ etc ( and vector_c for that matter) the ideal would be for the above assertion to hold. int_'s and long_'s should be standalone types which have their own semantics. I think its not too difficult to add rules for how they interact with integral_c as well.

Go for it.

As it stands mpl::plus assumes everythings an integral constant and perversely it actually reinforces that in code by giving back an integral_c whatever the actual integral_constant inputs are.

Whether that's perverse or not is obviously a matter of opinion.

This as well as seeming arbitrary, makes int_'s and long_'s and vector_c basically superfluous IMO.

They're not superfluous: they save loads of typing. I would hate to do without them.

The current definition of mpl::plus (et al) strikes me as odd too with its tight coupling and assumption that its operands are integral-constants. plus and other arithmetic ops could be 'just an operator' with the result type solely dependent on the operands. I remember you arguing against this for mpl.. "concept overloading" was it? but cant remember why

I don't know what you're talking about. I have no problem with plus being applied to other kinds of numerical wrapper types. -- Dave Abrahams Boost Consulting www.boost-consulting.com