[boost] Re: Proposal: type-promoting arithmetics for derivative types

From: Max Motovilov (max_at_[hidden])
Date: 2004-02-25 19:27:56

"Brian McNamara" <lorgon_at_[hidden]> wrote in message
news:20040225235607.GA1327_at_gaia3.cc.gatech.edu...

> See, e.g.
>    http://www.boost.org/libs/lambda/doc/ar01s06.html
> operator-tag representations as well as the logic that "when combining
> float and double, promote both to double" already exist somewhere in
> Boost (ask Joel or Jaakko, I dunno the details), so reuse those.

Looks exactly like what I was proposing, even the syntax is similar. I knew
it had to be there somewhere :)

> My hunch is that this bit will work better if you use MPL (rather than
> have template-template parameters, you can treat the class as a
> metafunction (e.g. std::complex<_1>) which can be "apply"ed.

template-template parameters were incidental to using standard library
"functors" as tags, but it looks like BLL has a complete solution for this
part already.

> > template< typename T1, typename T2 > struct promoted_type< T1, T2,
std::plus
> > >
> > {
> >     enum { tag = sizeof( typeof_one_of_two<T1,T2>::typeof_fun( T1() +
> > T2() ) ) };
> >     typedef typename typeof_one_of_two<T1,T2>::select_type< tag >::type
> > type;
> > };
>
> Also, here you presume default constructors for T1 and T2; make sure the
> actual implementation avoid this.

Point taken. While it is not unreasonable to expect an arithmetic type to
have a default constructor, it is better not to impose an unnecessary
requirement.

> I'm sure there's a bit to hammer out with respect to the details, but
> yeah, I like the idea of using a specialization to say "I want this
> trick enabled" and then using enable_if with a general operator@()
> template to do the automatic promotion work.

I still have not decided whether I "trust" the SFINAE-based constructs
enough to rely on them fully for protection against unintended implicit
specializations... feedback from people who have more experience with
enable_if et. al. would be greatly appreciated. Also, I don't like to have a
library introduce operator definitions into global namespace but I have not
yet invented a way to avoid it in this context. Any ideas?

Regards,
...Max...