Peter Dimov wrote:
I'm really not sure what do you mean by "modern" boost requirements.
None of the libraries that have recently been included into boost placed their headers in the boost root directory. I don't know whether this has become a (formal) requirement but that's what I wanted to express.
a) this header should be placed in the bind subdirectory, e.g. boost/bind/bind.hpp
What purpose does that serve? Why not boost/bind/bind/bind.hpp?
It was just an idea how to separate this header from the existing. One of many possible.
b) this header should introduce a separate namespace 'bind' or 'function' to avoid the well-known namespace clashes with boost::lambda that are _really_ annoying.
Again, what purpose would that serve? The only name that bind.hpp "reserves" in boost is 'bind'. Defining a namespace 'bind' still reserves the same name in boost, namely, 'bind', except that user code is now uglier.
Try to include boost/bind.hpp and boost/lambda/bind.hpp at the same time (just for matters of uniformity: this is the first time where I don't agree that one of those includes is in a subdirectory and the other is not!) I've not found any solution for how to use e.g. _1 from boost.lambda in one function and _1 from boost.bind in another _without_ having to qualify these two everytime, which is totally ugly IMO.
The original intent has been to make the placeholders globally available. As identifiers that start with an underscore are not allowed at the global namespace, and since defining a variable in a header would cause link errors, the placeholders have been put in an unnamed namespace.
ah ... I understand. IIRC, the _1 from boost.lamba are types and don't have these problems therefore. This means more or less that I'll never be able to write 'using boost::_1', no? Stefan