[bind] Placeholders suggestion, std and boost
I realize that changing boost::bind so by default that placeholders of
the form _n needing some sort of namespace in front of it will break
plenty of code, so I am not suggesting doing that. What I would like to
suggest is a Boost.bind macro, which when used before including
On Sun, May 24, 2015 at 6:21 PM, Edward Diener
I realize that changing boost::bind so by default that placeholders of the form _n needing some sort of namespace in front of it will break plenty of code, so I am not suggesting doing that. What I would like to suggest is a Boost.bind macro, which when used before including
, would put the boost::bind placeholders of the form _n in a boost::placeholders namespace.
I propose creating
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace.
That's not a bad plan, but it would've been even better if boost/bind/bind.hpp didn't already exist. :-)
#include
using boost::placeholders::_1;
I'm having a bit of trouble deciding between the above and using namespace boost::placeholders; The using declarations are closer to the current code and would be a better bet compatibility-wise, but the using directive seems more correct somehow.
On 5/25/2015 7:12 AM, Peter Dimov wrote:
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace. That's not a bad plan, but it would've been even better if boost/bind/bind.hpp didn't already exist. :-)
Maybe boost/bind/library.hpp ( or boost/bind/all.hpp )
#include
using boost::placeholders::_1;
I'm having a bit of trouble deciding between the above and
using namespace boost::placeholders;
The using declarations are closer to the current code and would be a better bet compatibility-wise, but the using directive seems more correct somehow.
As long as the boost::placeholders namespace consists of only the declarations of _1 through _9, as in the current boost/bind/placeholders.hpp, the using directive seems fine.
On Mon, May 25, 2015 at 4:12 AM, Peter Dimov wrote:
Glen Fernandes wrote:
#include
using boost::placeholders::_1;
I'm having a bit of trouble deciding between the above and
using namespace boost::placeholders;
The using declarations are closer to the current code and would be a better bet compatibility-wise, but the using directive seems more correct somehow.
With the former, ::boost::placeholders::detail (if it exists now, or will in the future) would not become ::detail, if that matters. Glen
Glen Fernandes wrote:
On Mon, May 25, 2015 at 4:12 AM, Peter Dimov wrote:
Glen Fernandes wrote:
#include
using boost::placeholders::_1;
I'm having a bit of trouble deciding between the above and
using namespace boost::placeholders;
The using declarations are closer to the current code and would be a better bet compatibility-wise, but the using directive seems more correct somehow.
With the former, ::boost::placeholders::detail (if it exists now, or will in the future) would not become ::detail, if that matters.
There'll be nothing in boost::placeholders except _1.._9. Not 100% sure
about the future.
The using directive allows you to declare your own _1 in the global
namespace:
#include
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace.
Done on develop (with a using directive.)
On 05/26/2015 03:32 PM, Peter Dimov wrote:
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace. Done on develop (with a using directive.)
Nice! -- Michael Caisse ciere consulting ciere.com
On Tue, May 26, 2015 at 3:32 PM, Peter Dimov
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace. Done on develop (with a using directive.)
Looks good!
On 5/26/2015 6:32 PM, Peter Dimov wrote:
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace. Done on develop (with a using directive.)
Thanks !
On 5/26/2015 6:32 PM, Peter Dimov wrote:
Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace. Done on develop (with a using directive.)
I gather that to use bind with the placeholders in the
boost::placeholders namespace you '#include
When the placeholders were moved there was also a change in the way they are defined in bind/placeholders.hpp There were three different definitions which were decided using various compiler definitions. That has now been simplified to two versions, based only on #if defined(BOOST_NO_CXX11_CONSTEXPR) // one option (non C++11) #else //another option #endif This action is breaking some code, in particular bind_interoperation_test on boost phoenix develop for non-C++11 test cases Initial tests show that replacing the one non C++11 with the previous three cases restores the test. Would you please look at this? Thanks John Fletcher ________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 26 May 2015 23:32 To: boost@lists.boost.org Subject: Re: [boost] [bind] Placeholders suggestion, std and boost Glen Fernandes wrote:
I propose creating
. Including it should result in the placeholders being in boost::placeholders namespace. would now do nothing more than just include and bring all the placeholders into the global namespace.
Done on develop (with a using directive.) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Fletcher, John P wrote:
When the placeholders were moved there was also a change in the way they are defined in bind/placeholders.hpp
There were three different definitions which were decided using various compiler definitions.
That has now been simplified to two versions, based only on
#if defined(BOOST_NO_CXX11_CONSTEXPR) // one option (non C++11) #else //another option #endif
This action is breaking some code, in particular bind_interoperation_test on boost phoenix develop for non-C++11 test cases
Initial tests show that replacing the one non C++11 with the previous three cases restores the test.
Would you please look at this?
Yes, I will. Marcel Raad also reported this breakage. I'll experiment with other "cleaned-up" placeholder definitions until we find one that is reasonably backward-compatible.
Fletcher, John P wrote:
This action is breaking some code, in particular bind_interoperation_test on boost phoenix develop for non-C++11 test cases
Would you be so kind as to distill this failure into a minimal test case that doesn't depend on Phoenix, so that I can add it to the Bind test suite? In this way we'll make sure that regressions are caught earlier in the pipeline.
Fletcher, John P wrote:
This action is breaking some code, in particular bind_interoperation_test on boost phoenix develop for non-C++11 test cases
Would you be so kind as to distill this failure into a minimal test case that doesn't depend on Phoenix, so that I can add it to the Bind test suite? In this way we'll make sure that regressions are caught earlier in the pipeline.
Never mind, no need. I'd argue that the problem is actually in phoenix::bind, it takes its arguments by const reference (as opposed to boost::bind by value and std::bind by &&+decay) and consequently fails cases like f.ex. int * g( int * p ) { return p; } int main() { int v[ 5 ] = { 0 }; boost::phoenix::bind( g, v )(); } but a regression is still a regression.
________________________________________
Fletcher, John P wrote:
This action is breaking some code, in particular bind_interoperation_test on boost phoenix develop for non-C++11 test cases
Would you be so kind as to distill this failure into a minimal test case that doesn't depend on Phoenix, so that I can add it to the Bind test suite? In this way we'll make sure that regressions are caught earlier in the pipeline.
Never mind, no need.
I'd argue that the problem is actually in phoenix::bind, it takes its arguments by const reference (as opposed to boost::bind by value and std::bind by &&+decay) and consequently fails cases like f.ex.
int * g( int * p ) { return p; } int main() { int v[ 5 ] = { 0 }; boost::phoenix::bind( g, v )(); }
but a regression is still a regression.
Thank you for this diagnosis. I will look into a smaller example. I will look into it further. The intention of the design of phoenix is to be compatible with bind, This is not completely achieved anyway. John
Fletcher, John P wrote:
Thank you for this diagnosis. I will look into a smaller example.
I will look into it further. The intention of the design of phoenix is to be compatible with bind, This is not completely achieved anyway.
The regression should now be fixed with https://github.com/boostorg/bind/commit/2ee272fa8d5a969d5c7516e98077026640d1...
participants (5)
-
Edward Diener -
Fletcher, John P -
Glen Fernandes -
Michael Caisse -
Peter Dimov