Re: [boost] [result_of, tr1] decltype and incomplete types

Subject: Re: [boost] [result_of, tr1] decltype and incomplete types
From: Eric Niebler (eric_at_[hidden])
Date: 2010-04-12 13:39:27

On 4/12/2010 1:50 AM, John Maddock wrote:
>> Note that to make this happen, you'll need to coordinate with John. The
>> way Boost.TR1 works is like this:
>>
>> - If the platform implements <tr1/foo_header>, include it. Otherwise,
>> - Include <boost/foo_header.hpp> and bring boost::foo into the std::tr1
>> namespace with a using declaration.
>>
>> If boost::result_of sometimes uses decltype, the above won't work
>> because then std::tr1::result_of will sometimes use decltype. It seems
>> to me that <boost/utility/result_of.hpp> should expose a
>> boost::tr1_result_of that can be used by <boost/tr1/result_of.hpp> to
>> get the TR1 behavior regardless of whether decltype exists or not.
> 
> Nod, I've had to do something similar with some type_traits classes when
> they changed from TR1 to C++1x.
> 
> Can someone who understands the issues please work out a patch?

John, I have attached a patch to
https://svn.boost.org/trac/boost/ticket/4084. Please look it over and
commit it to trunk if you accept it. Daniel Walker, the result_of
maintainer, has already approved it. Or just let me know and I'll apply it.

> Also note that providing an "archived" TR1 version of result_of won't
> help other Boost code that relies on boost::result_of - some of which
> may also get imported and/or used by the TR1 lib :-(

Crap. I guess any component of any TR1 library that depends on result_of
will need to come in two flavors. The Boost.TR1 library's version will
select the appropriate one. That's ugly. Or we can just say it's a known
Boost.TR1 bug and live with it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com