Bind review comments

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-08-20 13:42:16

I think that Bind is a good library and should be included into boost, subject to dealing with the following two issues:

(1) There are names that are not in the boost namespace.  This needs to be changed to avoid a conflict.  The existence of an anonymous namespace does not help.  Imagine an author of some other library, say Bond, decided to use names like Bind does, and a piece of user code happens to use both libraries.  The result would be

#include <boost/bind.hpp>
#include <james/bond.hpp>
...
boost::bind(f, _0)(x);
james::bond(g, _0, _0, _7)(a,b,c,d,e,f,g,h);

with the _0 being ambiguous.  Normally, a user who is interested in protecting himself from such a conflict can use namespaces to prevent this, especially since the above code may come from two modules that were at one time independent.  Bind has taken that option away from the user.  This is the same sin (only to a less degree) as defining ones own pseudo-keywords using macros (e.g. signal).

A less in intrusive solution is to define _0, _1, ... _7, ref, and cref, in namespace boost, then create a subnamespace called, say "argument", which declares all those names using using declarations.  Then a user can simply write "using namespace boost::argument;" if unqualified _0 is desired, but the boost will is not forced on the just by virtue of bind.hpp being included.

Note that this issue is complete separate from what to call _0, _1, etc., as the problem applies no matter what the names are.

(2) The mem_fun conflict with the functional library needs to be remedied.  So long as boost is distributed as a single collection, the users assumption that it doesn't trip over itself should be valid.  Condition inclusion hacks are not the solution.  The solution is to choose the mem_fun implementation that best fits the name mem_fun and go with that.  Any remaining mem_funish item needs a new name.

Additionally, I have the following comments, although I don't think they should affect acceptance:

(3) I think the _1 format is excellent.  Clear, concise, and compatible.  It will be consistent with the future printf replacement library, which will likely use the $1 format for equally good reasons.  Nothing else will.

In general, detection is the only significant concern of conflicts regarding names beginning or ending with an underscore.  If a name is found to conflict, and it is an implementation detail, it can easily changed.  If the name affects of the interface, a little macro magic can put in replace the conflicting name with a workaround name, with the advantage that the only the user of the conflicting legacy library needs to put up with the lesser name.  Detection can be tricky, but often the compiler will emit something indicating the code being substituted for the macro, and it is easy to check/defend against conflicting macros by putting #define _0 _0 in the code and watching for redefinition warnings.

(4) [nit] The fixed-width nature of the HTML page is annoying.  The width should vary with the browser window size.

(5) The use two different forms of inclusion (<boost/config.hpp> vs. "ref.hpp") doesn't make sense to me.  It seems that one consistent approach is used.  (I am assuming that bind.hpp will go into the boost/ header directory.)