"Brian McNamara" <lorgon@cc.gatech.edu> wrote in message news:20040225235607.GA1327@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...