Hi, I have a problem with Boost.Bind placeholders. Namely, once I include the <boost/bind.hpp> it automatically brings placeholders _1, _2, .. into scope and I cannot use placeholders from other libraries like Spirit.Qi any more. I.e. I can but I need to qualify them like qi::_1, qi::_2, which is annoying. I include <boost/bind.hpp> in a precompiled header, so I have no option of not including it. Boost.Bind could define them in namespace boost::bind_placeholders and we could control their visibility with namespace using directive. This is what Spirit does, and it is cute. I guess I would not be able to convince anyone that Bind should do the same. But would it be possible to define placeholders _1, _2, ... as something more generic in Boost, unrelated to any particular library? Then boost::bind, would treat it as its own placeholders, Spirit semantic actions would treat them as its own placeholders, but they would be exactly same placeholders. Regards, &rzej
On 7/27/2010 11:41 PM, Andrzej Krzemienski wrote:
Hi, I have a problem with Boost.Bind placeholders. Namely, once I include the<boost/bind.hpp> it automatically brings placeholders _1, _2, .. into scope and I cannot use placeholders from other libraries like Spirit.Qi any more. I.e. I can but I need to qualify them like qi::_1, qi::_2, which is annoying. I include<boost/bind.hpp> in a precompiled header, so I have no option of not including it. Boost.Bind could define them in namespace boost::bind_placeholders and we could control their visibility with namespace using directive. This is what Spirit does, and it is cute. I guess I would not be able to convince anyone that Bind should do the same. But would it be possible to define placeholders _1, _2, ... as something more generic in Boost, unrelated to any particular library? Then boost::bind, would treat it as its own placeholders, Spirit semantic actions would treat them as its own placeholders, but they would be exactly same placeholders.
Yes, it is possible. That is what we are trying to solve with the Phoenix-3 project: unification of all placeholders. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
At Wed, 28 Jul 2010 09:05:07 +0800, Joel de Guzman wrote:
Yes, it is possible. That is what we are trying to solve with the Phoenix-3 project: unification of all placeholders.
Not quite possible since MPL placeholders (at least in C++03) have to be types rather than objects :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 07/28/2010 05:17 AM, David Abrahams wrote:
At Wed, 28 Jul 2010 09:05:07 +0800, Joel de Guzman wrote:
Yes, it is possible. That is what we are trying to solve with the Phoenix-3 project: unification of all placeholders.
Not quite possible since MPL placeholders (at least in C++03) have to be types rather than objects :-)
Out of curiosity, how might it be possible with C++1x if that is what you are referring to?
At Wed, 28 Jul 2010 17:02:34 -0700, Jeremy Maitin-Shepard wrote:
On 07/28/2010 05:17 AM, David Abrahams wrote:
At Wed, 28 Jul 2010 09:05:07 +0800, Joel de Guzman wrote:
Yes, it is possible. That is what we are trying to solve with the Phoenix-3 project: unification of all placeholders.
Not quite possible since MPL placeholders (at least in C++03) have to be types rather than objects :-)
Out of curiosity, how might it be possible with C++1x if that is what you are referring to?
decltype makes it possible to build a much more runtime-ey MPL—it would look quite different though—where the placeholder objects could be useful. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (5)
-
Andrzej Krzemienski -
David Abrahams -
Jeremy Maitin-Shepard -
Joel de Guzman -
joel falcou