Re: [boost] Recent config changes?

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-05-23 16:17:19

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 23, 2002 2:23 PM
Subject: Re: [boost] Recent config changes?

>
> ----- Original Message -----
> From: "John Maddock" <john_maddock_at_[hidden]>
>
> > > Yes! Did you test with STLPort? boost/detail/iterator.hpp is making
the
> > > assumption that they're mutually exclusive.
> > > I can work around it for this one file, but what could the possible
> > > justification be for enabling BOOST_MSVC_STD_ITERATOR with STLPort?
> It's
> > > supposed to mean
> >
> > The ublas guys wanted it - std::iterator is the basically the same with
> or
> > without STLport on MSVC isn't it?
>
> No. I can find no similarity whatsoever in those two definitions of
> iterator.

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.

> > I do know that reverse_iterator differs a
> > lot, but I think that array was the only use for that case and that
> tested
> > 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 ;-)

> Please! And next time I think it would be good to at least give a public
> heads-up before we change the meaning of a configuration flag, since the
> consequences can be so far-reaching.

Sorry for causing harm.

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

Regards

Joerg