Subject: Re: [boost] [Proto] BOOST_PROTO_USE_NORMAL_RESULT_OF seems incorrectly defined
From: Hui Li (hui.li_at_[hidden])
Date: 2013-12-31 14:00:54
Eric, thanks for replying. I have created a ticket: https://svn.boost.org/trac/boost/ticket/9538 .
I did run into problem when testing out a callable transform that doesn't implement the nested result<> template class nor the result_type member, in xcode 5 (clang) with -std=c++11.
The compile error points to proto/detail/poly_function.hpp line 205, which reads
typedef typename Fun::template result<Sig>::type result_type;
I try to change it to
typedef typename BOOST_PROTO_RESULT_OFF<Sig>::type result_type;
but still doesn't compile.
however, changing to boost::result_of<> works,
typedef typename boost::result_of<Sig>::type result_type;
so I looked into the definition of BOOST_PROTO_RESULT_OFF, which led to BOOST_PROTO_USE_NORMAL_RESULT_OF.
I did a quick search in proto and phoenix, and found several places where the nested result<> template class or the result_type member were directly accessed when determining the return types. I wonder if they should be boost::result_of<> instead (or BOOST_PROTO_RESULT_OFF)?
On Dec 31, 2013, at 12:13 PM, Eric Niebler <eniebler_at_[hidden]> wrote:
> On 12/31/2013 05:56 AM, Hui Li wrote:
>> In proto/proto_fwd.hpp, based on how the macro BOOST_PROTO_USE_NORMAL_RESULT_OF is used, it's meant to be defined when the compiler supports c++11 decltype and implements N3276, for example, BOOST_PROTO_RESULT_OF is boost::result_of when BOOST_PROTO_USE_NORMAL_RESULT_OF is defined.
>> However, its definition seems incorrect, and is inconsistent with the comments next to it.
>> #ifdef BOOST_NO_CXX11_DECLTYPE_N3276
>> ^^^^^^ should this be #ifndef ?
>> # // Proto can only use the decltype-based result_of if N3276 has been
>> # // implemented by the compiler.
>> # // See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf
>> # ifndef BOOST_PROTO_USE_NORMAL_RESULT_OF
>> # define BOOST_PROTO_USE_NORMAL_RESULT_OF
>> # endif
>> Am i missing something here?
> I agree, that looks suspicious. Is it causing problems? I don't have
> time to investigate at the moment. Could you please file a bug so I
> don't lose track of this?
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk