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

Top posting because I'm going to remark about this thread in general, but this message is a fine example. Andy seems to be speaking (mostly) about int_<>, integral_c, etc (I'll just say the incorrect 'int<>') and plus; David is talking about transform. I think, but can't say for sure, that Andy wants plus to work 'as expected' and always return int<>, not just 'concept-identical' to int. Maybe it does, I'm not sure. And/or he wants transform ***when applied to int<> with plus, etc*** to return int<>. David, says, that ***in general*** transform can't make the return type "match" (in Andy's stricter sense) the inputs. Maybe it could for the special case of int<>? IMO, that would be quite hard, as the point of the templates is to be general. Do I have this right, in any sense? P.S. for David, below: Date: Sat, 25 Feb 2006 10:22:57 -0500

From: David Abrahams Subject: Re: [Boost-users] [mpl] newbie question To: boost-users@lists.boost.org Message-ID: Content-Type: text/plain; charset=us-ascii

"Andy Little" 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 + vector_c = vector_c

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"

the line above says "the transform"

...

...

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. as mentioned, he did, but that doesn't mean I understand the point he is trying to make. 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 >::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