Re: [boost] Recent config changes?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-23 16:44:08

----- Original Message -----
From: "Joerg Walter" <jhr.walter_at_[hidden]>
>
> The main problem concerned std::reverse_iterator. After porting to
> boost.config we usually distinguish MSVC and non MSVC environments
regarding
> iterators in the following way:
>
> #ifdef BOOST_MSVC_STD_ITERATOR
>
>     template <class I, class T, class R>
>     class reverse_iterator:
>         public std::reverse_iterator<I, T, R> {
>         ...
>     };
>
> #else
>
>     template <class I>
>     class reverse_iterator:
>         public std::reverse_iterator<I> {
>         ...
>     };
>
> #endif
>
> This failed for one of our users with MSVC 6.0 and STL-Port 4.5.3. After
> some investigation I found the following defininition in _iterator_old.h:
>
> #if ! defined ( _STLP_CLASS_PARTIAL_SPECIALIZATION )
>
> // This is the old version of reverse_iterator, as found in the original
> //  HP STL.  It does not use partial specialization.
>
> template <class _RandomAccessIterator,
> # if defined (__MSL__) && (__MSL__ >= 0x2405) \
>  || defined(__MRC__) || defined(__SC__)  //*ty 03/22/2001 - give the
default
> to the secont param under MPW.
>             // I believe giving the default will cause any harm even
though
> the 2nd type parameter
>             // still have to be provided for T* type iterators.
>
__DFL_TMPL_PARAM(_Tp,iterator_traits<_RandomAccessIterator>::value_type),
> # else
>  class _Tp,
> #endif
>  __DFL_TMPL_PARAM(_Reference,_Tp&),
> # if defined (_STLP_MSVC50_COMPATIBILITY)
>         __DFL_TMPL_PARAM(_Pointer, _Tp*),
> # endif
>         __DFL_TYPE_PARAM(_Distance,ptrdiff_t)>
> class reverse_iterator {
> ...
> };
>
> #endif
>
> which automagically seems to match the Dinkumware definition of
> std::reverse_iterator. So I asked, why the corresponding detection in
> boost.config was disabled. BTW, the combination MSVC 6.0 and
STLPort-4.5.3
> works fine if BOOST_MSVC_STD_ITERATOR is set.

...unless you use Boost headers which assume the meaning of
BOOST_MSVC_STD_ITERATOR matches its documentation. Silly headers.

> > > OK, as did utility/iterator_test.cpp when I tried it.  However if
it's
> > > causing problems disable it again, and let the ublas guys find some
> other
> > > workaround.
>
> A possible workaround is to add a boost.config like detection locally ;-)

Just use the right test: check for
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, as every such compiler will need
the extra template parameters in order to make reverse_iterator work.

> Sorry for causing harm.

Forgiven; but please undo it quickly.

> > > >     "Microsoft's broken version of std::iterator is being used.
This
> > > > implies that std::iterator takes no more than two template
parameters,
> > and
> > > > that std::reverse_iterator takes at least two template parameters."
> > > >
> > > > And that's clearly false with STLPort.
> > >
> > > Maybe we need BOOST_STLPORT_ITERATOR for the non-standard STLport
> > version,
> > > but we've got enough macros already :-(
> >
> > The only non-standard part of the STLPort+MSVC version is this
> > specialization, which I think we can just check for by looking for
> > __SGI_STL_PORT:
> >
> >     template <>
> >     struct iterator<output_iterator_tag, void, void, void, void>
> >     {
> >         typedef output_iterator_tag iterator_category;
> >     };
>
> No, std::reverse_iterator behaves different, at least under certain
> circumstances.

Please show me where std::reverse_iterator is mentioned in the
documentation for BOOST_MSVC_STD_ITERATOR. I claim it's irrelevant.

-Dave