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 <
dave@boost-consulting.com>
Subject: Re: [Boost-users] [mpl] newbie question
To: boost-users@lists.boost.org
Message-ID: <
uoe0v799q.fsf@boost-consulting.com>
Content-Type: text/plain; charset=us-ascii
"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"
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<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