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

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-26 14:42:23

"Gottlob Frege" <gottlobfrege_at_[hidden]> writes:

> 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.  

Andy, please take note: what you want is still unclear to people other
than me.

Since "as expected" is vague, and your statement seems a little too
sweeping, I'll say it this way:

  I (Dave) think, but can't say for sure, that Andy wants plus to
  always return an int_ specialization when all the inputs are
  specializations of int_.

I think, but can't say for sure, that he also wants a different
specification for the behavior of plus, and all the other arithmetic
operators.

> 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.

I don't think we can do it.  However, it's certainly possible to make
the *elements* of the resulting container be int_ specializations
whenever the operation has the form:

      transform<s1, s2, op<_,_> >

where s1 and s2 contain only specializations of int_ and op is an MPL
arithmetic operation.

Whether making that so is worth the costs or not, as far as I'm
concerned, remains to be seen.  I'd need to see code, and see evidence
that this issue is actually the source of Andy's difficulties with
compilation speed.  And of course, Aleksey would need to render final
judgement as the MPL maintainer.

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