"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
I think we need a little bit more context here.
OP David Abrahams
Andy Little (me)
Just trying to use mpl::transform on a vector of int's and I can't seem to get it working properly. Can anyone see what's wrong?? I'm trying to perform
vector_c<int, 1, 2, 3> + vector_c<int, 1, 1, 1> = vector_c<int, 2, 3 ,4>
The is_same function always returns false when I compile and run it.
The result of the transform is only required to be "concept-identical" to the result you're looking for.
IMO that behaviour is sloppy. I see no reason why (at least)
boost::is_same < plus< int_<1> ,int_<1> >::type, int_<2> > shouldnt be true.
Your change from "the transform" to "being about transform" above is problematic for me.
I don't know what you mean. Nobody wrote "the transform" above. Don't make this complicated. It is very simple: I made a statemnt *about the behavior of transform*, and you replied "that behavior is sloppy," and then proceeded to go on about something only distantly related (the type of results of arithmetic operations). The behavior I was describing is not sloppy. To make the library behave differently would introduce a huge overhead in implementation code that is more likely than not to slow down compilation of user programs. Let me be a little more explicit: transform<vector_c<int, ...> >::type is likely to be a specialization of vectorN where N is a numeral. Therefore, testing it against a vector_c specialization using is_same will always fail. That is the behavior I was referring to. I wouldn't care much what you said, except for that you're doing this in a thread where impressionable "newbies" are reading, and I don't want them to misunderstand the library design or the implementation decisions and their costs/benefits. Your statement above not only unfairly maligns Aleksey's work, it is misleading. -- Dave Abrahams Boost Consulting www.boost-consulting.com