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
> (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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk