Re: [boost] Big checkin, lots of fixes

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-01-21 15:39:13

----- Original Message -----
From: "Jens Maurer" <Jens.Maurer_at_[hidden]>

> David Abrahams wrote:
> >
> > New Files:
> >   boost/detail/iterator.hpp
> >     Portable working versions of the following, in namespace detail:
> >       std::iterator_traits<>::iterator_category
> >       std::iterator_traits<>::difference_type
> >       std::distance()
>
> We already have a boost/iterator.hpp which is supposed to supply
> a replacement for std::iterator.
>
> Can we please merge the two header files?
>
> I believe that all compiler/library workarounds should vanish one day
> (when all compilers/libraries are compliant), thus I think these
> bug workarounds should not have the same status as other boost
> contributions which provide value in addition to the standard library.

Which is one reason my contribution is in detail

> On the other hand, these fixes to not have "detail" status, because we
> (should) document these fixes and these help the end-user write more
> portable programs as well.

I'm not ready to put it through the formal review process. This is just
something I needed in order to properly respond to some of Steve Cleary's
comments about iterator_adaptors. So, as I try to prepare that for release,
I need some new stuff in detail. Complicated, isn't it?

> Could we have a boost/std-bugfix with the following policy:
>
> "The boost/std-bugfix directory contains header files with the
> same name as the ISO C++ standard header files, with a .hpp suffix
> appended, e.g. boost/std-bugfix/iterator.hpp.  These files intend
> to provide bug fixes to the vendor-provided standard library
> implementations while these implementations are in the process of
> becoming ISO conformant.  If some header file in boost/std-bugfix/XXX.hpp
> exists, you should use it unconditionally when writing boost code
> instead of the standard <XXX>, so that portability is enhanced.
> All names in these headers should be in namespace boost or
> boost::detail."
>
> (Would a namespace boost::std_bugfix be better?  I don't think so,
> because it uglifies user code rather heavily.)
>
> The advantage of moving these files out of boost/ is that it removes
> clutter in boost/ and makes users aware that they are not using
> some boost feature-enhanced class, but just the standard one with
> bugfixes.

boost/detail/iterator.hpp is kind of a wierd case. It obviously can't supply
all of std::iterator_traits on broken compilers, but it can give us
iterator_category and difference_type. Also, boost/iterator.hpp doesn't
purport to supply /everything/ in <iterator> (e.g. std::istream_iterator<>),
so I don't think your policy works as written.

> (A <limits> file for gcc would fit in there nicely.)

That would be a /big/ help!

> Note that feature fixes to the specified standard library (such
> as boost::integer_traits) should remain in the main boost directory.

That makes sense to me.

-Dave