[phoenix] conflicts between result_of namespace and result_of class.
Hi, I have found an error when we define new phoenix expression inside boost namespace. The following #include <boost/phoenix/core/limits.hpp> #include <boost/phoenix/core/call.hpp> #include <boost/phoenix/core/expression.hpp> #include <boost/phoenix/core/meta_grammar.hpp> #include <boost/phoenix/object/detail/target.hpp> #include <boost/proto/transform/lazy.hpp> #include <boost/phoenix/core/is_actor.hpp> BOOST_PHOENIX_DEFINE_EXPRESSION( // line 19 (boost)(convert_to) , (proto::terminal<boost::phoenix::detail::target<proto::_> >) (boost::phoenix::meta_grammar) ) results in darwin.compile.c++ ../../../bin.v2/libs/conversion_ext/test/builtins.test/darwin-4.2.1/debug/builtins.o builtins.cpp:19: error: ‘namespace boost::result_of { }’ redeclared as different kind of symbol ../../../boost/utility/result_of.hpp:35: error: previous declaration of ‘template<class F> struct boost::result_of’ builtins.cpp:19: error: ‘template<class F> struct boost::result_of’ used without template parameters builtins.cpp:19: error: expected unqualified-id before ‘<’ token It seems that the Phoenix result_of protocol and the utility result_of conflicts. Is this a real issue? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/phoenix-conflicts-between-result-of-names... Sent from the Boost - Dev mailing list archive at Nabble.com.
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) ) 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? If it isn't, what are the general rules of when something is considered for being resident in the boost namespace? Regards, Thomas
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.
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.
If it isn't, what are the general rules of when something is considered for being resident in the boost namespace?
I don't think that Boost must forbids the direct used of the boost namespace. I recognize that in general using a specific namespace is a good guideline, but I'm sure we want to use boost:: directly for the libraries that are accepted or candidate to the standard, but maybe others think differently. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/phoenix-conflicts-between-result-of-names... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
participants (2)
-
Thomas Heller -
Vicente Botet