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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-20 08:35:27

From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> 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.

Yes, and last I checked, finding the library you're interested in in the big
log file was not a pleasant experience. :-)

I want to propose a better solution. The tests should be organized in groups
by library. In addition to the full .cpp/result table we'll have a
'collapsed' table that would have library/result rows, with the results in a
'pass', 'fail', or '4/7' form. This will not only solve the problem with the
bind tests but apply to the already existing tests as well; for instance,
static_assert has 9 tests.

> > >  - 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.

Error messages become very long. This is important for libraries like Bind,
where reading and mentally decoding the error message is not easy even with
the short _bi prefix.

What are the benefits of having a 'detail' namespace? I try to use it
whenever possible, but in this particular case...

> > 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 :-)

Well I don't know, the original Tuple disabled ref/cref on MSVC and had a
somewhat reduced functionality so I decided to play it safe.

--
Peter Dimov
Multi Media Ltd.