Re: [boost] More comments on the Bind library submission?

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-08-19 11:26:16

Peter Dimov wrote:
> 
> From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> >  - I'd like to see the tests merged into one .cpp file so there's
> > only one more line in the tables for the regression test results.
> 
> The reason for the separate tests is that the library may be usable even
> when some of the tests fail. Having a single 'fail' line doesn't provide
> enough information.

We always have the full compiler output available for those who would
like to see the details.

> >  - The get_pointer() approach requires additional
> > co-operation from smart pointer classes not required
> > when using std::mem_fun_ptr.  Therefore, bind's mem_fun
> > is not a fully backwards-compatible substitute for
> > Boost.Functional's mem_fun_ptr (or std::mem_fun_ptr, for
> > that matter).
> 
> I don't understand this paragraph. std::mem_fun simply does not work with
> smart pointers, AFAIK.

Sorry, I was confused.

Re-thinking the issue, I'm (only) concerned not to replace the
easy and straight-forward extensions in Boost.Functional) with
the version in bind, which has had far less public exposure.

> >  - I don't like the _mfi and _bi namespaces.  Boost
> > uses the "detail" namespace for implementation details.  I hope
> > that's also stated in the library guidelines somewhere.
> 
> It is, but having a single 'detail' namespace is not enough. Name clashes in
> detail will become common; boost:: names are documented (most of the time)
> but boost::detail:: names are not.

Thus, have a boost::detail::bind namespace.

> > bind.hpp:
> >  - Could the implementation use the tuple library?
> 
> Yes, it could. Such a dependency has its pros (less work for me) and cons.
> For instance, bind.hpp will fail on every platform where tuple.hpp fails.

After the integration into the CVS, I'm curious whether bind fails
on different platforms than Boost.tuple :-)

Jens Maurer