Why is <boost::function>::_1 not in namespace boost?
Hi!
the placeholders in boost/bin/placeholders.hpp
are put in an anonymous namespace.
This is awkward, since like this they are visible
even in places where I do not want them to be so, e.g.:
#include
From: "Markus Werle"
Hi!
the placeholders in boost/bin/placeholders.hpp are put in an anonymous namespace.
This is awkward, since like this they are visible even in places where I do not want them to be so, e.g.:
#include
#include // not unlikely to use both
Why would you ever need to use
Peter Dimov wrote:
From: "Markus Werle"
Hi!
the placeholders in boost/bin/placeholders.hpp are put in an anonymous namespace.
This is awkward, since like this they are visible even in places where I do not want them to be so, e.g.:
#include
#include // not unlikely to use both Why would you ever need to use
and together? Lambda has its own bind.
Well, I just happen to have a class that a) uses boost::bind, etc to create functors, so ::_1 is visible and b) uses boost::lambda to remove all sort of loops so boost::lambda::_1 must be made visible. They are used _in_ _parallel_, not together. IMHO it is a good idea to have them both in name namespaces. Any good reason to leave them in :: scope? Markus
On Monday 27 January 2003 10:07 am, Markus Werle wrote:
They are used _in_ _parallel_, not together. IMHO it is a good idea to have them both in name namespaces.
Any good reason to leave them in :: scope?
Because writing boost::_1 is a lot of extra typing, and "using namespace boost" is not an option for all users (it brings in a lot of names that might conflict with user code). I keep hoping that Boost.Bind's _1 and Boost.Lambda's _1 will become the same entity at some point... Doug
From: "Douglas Gregor"
On Monday 27 January 2003 10:07 am, Markus Werle wrote:
They are used _in_ _parallel_, not together. IMHO it is a good idea to have them both in name namespaces.
Any good reason to leave them in :: scope?
Because writing boost::_1 is a lot of extra typing, and "using namespace boost" is not an option for all users (it brings in a lot of names that might conflict with user code).
Well said, thanks Doug. :-)
I keep hoping that Boost.Bind's _1 and Boost.Lambda's _1 will become the same entity at some point...
This is definitely the right thing to do in theory; in fact, even boost::bind and boost::lambda::bind should become the same entity. But it isn't easy.
Douglas Gregor wrote:
On Monday 27 January 2003 10:07 am, Markus Werle wrote:
They are used _in_ _parallel_, not together. IMHO it is a good idea to have them both in name namespaces.
Any good reason to leave them in :: scope?
Because writing boost::_1 is a lot of extra typing,
Well, assumed I have good reasons to use boost::bind and ::_1 in one case and boost::lambda::_1 in another place in the same file. Now there is a _lot_ of extra typing due to the ambiguity: using boost::lambda::_1; using boost::lamdba::bind; etc. If _1 from boost::function would reside in a named namespace (as does good and IMHO correctly implemnetd boost::lambda library) the name resolution side effects would vanish immediately
and "using namespace boost" is not an option for all users (it brings in a lot of names that might conflict with user code).
I agree. So what about another nested one: boost::function::placeholders
I keep hoping that Boost.Bind's _1 and Boost.Lambda's _1 will become the same entity at some point...
In 2012? Markus
On Monday 27 January 2003 10:51 am, Markus Werle wrote:
Well, assumed I have good reasons to use boost::bind and ::_1 in one case and boost::lambda::_1 in another place in the same file.
You could rename Lambda's placeholders to something that doesn't conflict with Boost.Bind's placeholders: http://www.boost.org/libs/lambda/doc/ar01s05.html
and "using namespace boost" is not an option for all users (it brings in a lot of names that might conflict with user code).
I agree. So what about another nested one: boost::function::placeholders
boost::function is part of the Function library, which is distinct from both Bind and Lambda, so I assume you mean boost::bind::placeholders. There are technical issues with that exact formulation (boost::bind can't be both a namespace and a function template), but I do not know why a similar solution was not implemented.
I keep hoping that Boost.Bind's _1 and Boost.Lambda's _1 will become the same entity at some point...
In 2012?
[Moderator: Do remember that Boost is a volunteer effort. No developer is obligated to fulfill user requests, and the motivation to do so is lessened by inflamatory remarks of this nature.] Doug
[Moderator: Do remember that Boost is a volunteer effort. No developer is obligated to fulfill user requests, and the motivation to do so is lessened by inflamatory remarks of this nature.]
OK, I retry to say what I mean in a serious way: Wrapping _1, _2 and other placeholders into a named namespace takes 5 minutes and saves a us from a lot of name ambiguities. Merging boost::lambda with similar parts of the boost lib will take forever and is a task no one really wants to fulfill. So IMHO the decision is easy. Note that I am perfectly happy with boost, except for the anonymous namespaces lurking around which I suspect to _always_ give me some extra headache since it opens the possibility for interference. Fortunately setting a prepro name will take that one away, but IMHO it should be the other way round. Your mileage may vary. Markus
From: "Markus Werle"
Peter Dimov wrote:
Why would you ever need to use
and together? Lambda has its own bind. Well, I just happen to have a class that a) uses boost::bind, etc to create functors, so ::_1 is visible and b) uses boost::lambda to remove all sort of loops so boost::lambda::_1 must be made visible.
They are used _in_ _parallel_, not together.
But why aren't you using lambda::bind _in_ _parallel_ with the other lambda features? Is there a particular reason for it?
Peter Dimov wrote:
From: "Markus Werle"
Peter Dimov wrote:
Why would you ever need to use
and together? Lambda has its own bind. Well, I just happen to have a class that a) uses boost::bind, etc to create functors, so ::_1 is visible and b) uses boost::lambda to remove all sort of loops so boost::lambda::_1 must be made visible.
They are used _in_ _parallel_, not together.
But why aren't you using lambda::bind _in_ _parallel_ with the other lambda features? Is there a particular reason for it?
Well, I got the impression that boost::function stuff has some extra convenience not offered by boost::lambda::bind et. al.. Do I understand You correctly, that You ask me to use boost::lambda::features everywhere instead of boost::function? Is there a 1-to-1 correspondencce in functionality? Is every boost::function feature available in boost::lambda or vice versa? I just argue that it _should_ be possible to use both of them in the same compilation unit without name clashes. This is what namespaces originally were invented for ... (of course since ADL the goal is missed and C++ is broken) Markus
From: "Markus Werle"
Peter Dimov wrote:
But why aren't you using lambda::bind _in_ _parallel_ with the other lambda features? Is there a particular reason for it?
Well, I got the impression that boost::function stuff has some extra convenience not offered by boost::lambda::bind et. al.. Do I understand You correctly, that You ask me to use boost::lambda::features everywhere instead of boost::function?
boost::function is a separate library. It can be used with boost::bind, and it can be used with Lambda. I asked you whether you have a particular reason to prefer boost::bind over boost::lambda::bind.
Is there a 1-to-1 correspondencce in functionality?
Almost. The differences between boost::bind and lambda::bind are enumerated here: http://www.boost.org/libs/lambda/doc/ar01s08.html#id2808613
I just argue that it _should_ be possible to use both of them in the same compilation unit without name clashes. This is what namespaces originally were invented for ...
Historically, conflicts between Bind and Lambda were almost never a problem, since there is rarely a reason to use both; the two libraries complement each other as Bind is typically used on non-conformant compilers where Lambda is not supported. The long term goal has always been to have one library. Unfortunately, the underlying architectures of Bind and Lambda are too different and it's not easy to just merge them while still retaining support for MSVC 6, for example. So it's a case of "if it ain't broken, don't fix it".
Peter Dimov wrote:
boost::function is a separate library. It can be used with boost::bind, and it can be used with Lambda.
I asked you whether you have a particular reason to prefer boost::bind over boost::lambda::bind.
Oh, it was just for historical reasons: I built a 2000 line header which creates boost::functions out of compile-time differentiated expression templates and I just do not want to repeat that task in the near future. The header did undergo heavy testing and so switching that part to boost::lambda would be loosing two weeks of headache for nothing. Now I started iterating over arrays of boost::functions and found that boost::lambda had some nice gimmics like e.g. if_then_else_return or throw_exception, which I like to use I did not take the time to see if other parts of boost provide the same functionality, so maybe this is my fault ... OTOH I still cannot see why _any_ part of boost should be outside of namespace boost, since this can always interfere with what already exists or what will come in the future, therefore again - despite the possibility of a merge of boost::lambda with the rest: I find that if I want to use _1, etc (the arg<1>()) I should be asked to define a prepro constant (BOOST_USE_PLACEHOLDERS), not the other way round. Maybe user's code should look similar to -------------------- user.C -------------------------- #include "boost/convenience.h " using namespace boost::convenience; ------ EOF ---------------------------------- -----boost/convenience.h:------ namespace boost { namespace convenience { using boost::placeholders::_1; using boost::placeholders::_2; //etc. }} ----- EOF ------------------
Is there a 1-to-1 correspondencce in functionality?
Almost. The differences between boost::bind and lambda::bind are enumerated here:
let me cite the link You gave: "The libraries can coexist, however, as the names of the BB library are in boost namespace, whereas the BLL names are in boost::lambda namespace." Well said, but untrue for _1;
I just argue that it _should_ be possible to use both of them in the same compilation unit without name clashes. This is what namespaces originally were invented for ...
Historically, conflicts between Bind and Lambda were almost never a problem, since there is rarely a reason to use both; the two libraries complement each other as Bind is typically used on non-conformant compilers where Lambda is not supported.
I see.
The long term goal has always been to have one library. Unfortunately, the underlying architectures of Bind and Lambda are too different and it's not easy to just merge them while still retaining support for MSVC 6, for example. So it's a case of "if it ain't broken, don't fix it".
OK, but how about adding two lines that put _1 in namespace boost::placeholders? best regards, Markus
"Peter Dimov"
Historically, conflicts between Bind and Lambda were almost never a problem, since there is rarely a reason to use both; the two libraries complement each other as Bind is typically used on non-conformant compilers where Lambda is not supported.
The long term goal has always been to have one library. Unfortunately, the underlying architectures of Bind and Lambda are too different and it's not easy to just merge them while still retaining support for MSVC 6, for example. So it's a case of "if it ain't broken, don't fix it".
I think I agree with Markus that it is in fact broken. It's easy to imagine dependency scenarios like this: lambda <-- libA <-\ }--> App bind <-- libB <-/ The guy writing App shouldn't have to be aware of the dependency conflict between libA and libB. Incidentally, MPL had to move all of its placeholders when it turned out that Boost.Python was using bind. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
participants (4)
-
David Abrahams -
Douglas Gregor -
Markus Werle -
Peter Dimov