|
Boost : |
Subject: Re: [boost] [phoenix] conflicts between result_of namespace and result_of class.
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-05-26 06:57:09
On Wednesday, May 25, 2011 07:51:58 PM Vicente Botet wrote:
>
> Thomas Heller-7 wrote:
> >
> > On Wed, May 25, 2011 at 5:04 PM, Vicente Botet
> > <vicente.botet_at_[hidden]> wrote:
> >> Hi,
> >>
> >> I have found an error when we define new phoenix expression inside boost
> >> namespace.
> >>
> >> The following
> >>
> > <snip>
> >>
> >> BOOST_PHOENIX_DEFINE_EXPRESSION( // line 19
> >> (boost)(convert_to)
> >> , (proto::terminal<boost::phoenix::detail::target<proto::_> >)
> >> (boost::phoenix::meta_grammar)
> >> )
> >>
> > <snip>
> >> It seems that the Phoenix result_of protocol and the utility result_of
> >> conflicts.
> >>
> >> Is this a real issue?
> >
> > No I don't think so. Why does this need to in the boost namespace in
> > the first place?
> >
> > make it:
> > BOOST_PHOENIX_DEFINE_EXPRESSION( // line 19
> > (boost)(convert)(convert_to)
> > , (proto::terminal<boost::phoenix::detail::target<proto::_> >)
> > (boost::phoenix::meta_grammar)
> > )
> >
>
> This is what I have done to make it working. In addition others were already
> reclaiming a specific namespace for Boost.Conversion.
Isn't the convert_to phoenix expression node some implementation detail of your
library? Do users care about that detail?
> > namespace boost
> > {
> > using convert::convert_to;
> > }
> >
> > I don't know what currently is considered best practice, but isn't it
> > considered bad to put
> > stuff directly in the boost namespace?
> >
>
> The problem would be the same if Boost.Conversion had a class result_of
> inside boost::conversion.
> I don't know id the Boost.Phoenix documentation state explicitly that these
> macros introduce a namespace result_of, but it would be great if it does. I
> see that the documentation that the macro introduce the namespaces tag,
> expression and rule, but result_of is missing.
Right, the docs were missing ... these were some last minute changes i made for
the boostcon presentation. This is fixed now, thanks for pointing it out.
The rational behind the result_of namespace is as follows:
While boost::result_of<Signature> works for function object types, it does not
work for polymorphic free functions. Thus the namespace result_of is trying to
emulate the missing boost::result_of functionality.
A lot of other boost libraries do it the same way.
I think this is almost standard coding style for generic libraries in Boost.
Regards,
Thomas
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk