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@wanadoo.fr> 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