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

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-25 07:00:03

"Andy Little" <andy_at_[hidden]> 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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com