Re: [boost] limited form of type deduction

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-11 18:29:58

Peter Dimov <pdimov_at_[hidden]> wrote:
> Brian McNamara wrote:
>> On Sat, Oct 11, 2003 at 08:37:24PM +0300, Peter Dimov wrote:
>>> Joel de Guzman wrote:
>>> 
>>>>         typedef result_of_plus<int, double>::type result;
>>> 
>>> You should name that
>>> 
>>>     typedef result_of<plus(int, double)>::type result;
>>> 
>>> instead. :-)
>> 
>> There is a smiley, but seriously, if you did
>> 
>>    struct op_plus {
>>       template <class R> struct result;
>>       template <class F, class A1, class A2> struct result<F(A1,A2)> {
>>          typedef typename result_of_plus<A1,A2>::type type;
>>       };
>>    };
>>    // etc.
>> 
>> then
>> 
>>    typedef result_of< op_plus(int, double) >::type result;
>> 
>> would truly work.  (Names like op_plus are just used as tags which
>> stand for the corresponding C++ operators.)
> 
> Or even:
> 
> struct plus;
> 
> template<class A1, class A2> struct result_of<plus(A1, A2)>
> {
>     // result_of_plus<A1, A2> goes here
> };
> 
> struct plus
> {
>     template<class A1, class A2> typename result_of<plus(A1, A2)>::type
>         operator()(A1 const & a1, A2 const & a2) { return a1 + a2; }
> };
> 
> Which one is more "correct" is not clear. It's better to leave result_of
> unspecialized if your wonderful TR1 implementation always does the right
> thing. It's better to specialize it otherwise, since the nested result<>
> forwarding sometimes "breaks" SFINAE.
> 
> Let's just hope that one day the proper decltype() will arrive and render
> the issue moot.

Indeed! I hope that will be soon. In the meantime... 

<<< OT: I just couldn't believe the longevity of tools such as VC6 for instance. 
I'm quite sure bind will still support VC6 for a long time still, right? I'm now
in a crossroads on whether or not to leave old crippled compilers behind on 
new code being developed. I wonder what other people are thinking regarding
this? My strategy has always been: develop using fairly conforming compilers
and do the port later. But that "port later" thing takes too much energy! >>>

Cheers,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net