Daniel Walker wrote:
Hello,
TR1 section 3.6.4 says that placeholders should be default and copy constructible. However, on gcc and borland boost::bind placeholders are not copy constructible. I tried the following C++0x test.
#include <boost/tr1/functional.hpp> #include <boost/concept_check.hpp>
int main() { boost::function_requires< boost::DefaultConstructible< typeof(std::tr1::placeholders::_1) >
(); boost::function_requires< boost::CopyConstructible< typeof(std::tr1::placeholders::_1) > (); }
This works on gcc 4.1 with GNU's TR1 implementation, but when using Boost.TR1 the second concept check fails to compile.
[...]
The attached patch does this by introducing a macro BOOST_BIND_ENABLE_INLINE_PLACEHOLDERS. When it is defined placeholders are not objects with internal linkage, and their types do not meet the TR1 concept requirements; i.e. they're inline functions. When the macro is not defined placeholders are objects with internal linkage, and their types are both default and copy constructible. The macro is undefined by default. If a user needs inline placeholders for precompiled headers or whatever reason, they can make the trade off and define the macro. The patch also includes user documentation.
I'm not at all sure that breaking the code of all boost::bind users who happen to use precompiled headers with Borland and g++ is acceptable. On first reading, I was inclined to finish the sentence with "... merely in order to make an irrelevant concept check pass". On second reading, you probably have in mind the fact that Lambda takes its arguments by const reference (boost::bind takes them by value and the deduced type of _1 *is* CopyConstructible in this case.) I agree that this is a problem if we want placeholder interoperability under g++ and I'm not sure what is the best way to address the issue. I'm fairly certain that we ought to leave Borland users alone, though.