From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-04-26 20:01:48
Daniel Walker wrote:
> 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()
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk