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

From: Andy Little (andy_at_[hidden])
Date: 2006-02-25 08:16:10

"David Abrahams" wrote
> "Andy Little"writes:
>
>> "David Abrahams" wrote
>>> "Andy Little"  writes
>>>
>>>> "David Abrahams" wrote
>>>>> "Andy Little" writes
>>>>>> I am not concerned with the intractible problem of sequence identity
>>>>>> ( whatever that means) at the moment.
>>>>>
>>>>> Then what was this indictment about?
>>>>>
>>>>> Me:
>>>>>  > The result of the transform is only required to be "concept-identical"
>>>>>  > to the result you're looking for.
>>>>>
>>>>> You:
>>>>>  IMO that behaviour is sloppy.
>>>>
>>>> What can I say? I acknowledge that mpl is a monumental piece of work .
>>>> Wonderful... but far from perfect.
>>>
>>> I don't think the fact that it's imperfect gives you the right to
>>> label any arbitrary design decision as sloppy.
>>
>> I dont follow?  "any arbitrary decision"?
>
> Yes, in this case the particular design decision that
>
>  transform<some_template< ... >  >::type
>
> may not always be a specialization of some_template.
>
>>> You seem to have no justification at all for calling the behavior
>>> mentioned above "sloppy," notwithstanding that it reminds you of
>>> another behavior that you dislike.
>>
>> The behaviour of having a return type defined as a concept rather
>> than a type in this case is unnecessarily imprecise.
>
> You haven't proven that about transform, which is the case in
> question.
>
>> In practise (Based on my experience in pqs physical quantities
>> library) it causes an explosion of arbitrary types all meaning the
>> same thing. This in turn leads to slow compile times and overuse of
>> compiler resources and with the fatal effect in some cases, that the
>> compiler cannot cope resulting in a failed compilation.
>
>> An alternative suggestion is to explicitly specify what seems to be
>> the actual behaviour of arithmetic operations on int_'s, long's etc
>> in the documentation.
>
> Stop.  The statement in question is about transform, not about int_'s,
> long_'s, etc.  You condemned Aleksey's design decision about the
> result of transform and have repeatedly claimed that it is unnecessary
> and could easily be done better.  Please demonstrate, or retract your
> claim.

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.

regards
Andy Little