This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: rel_ops issues
- To: Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr (Gabriel Dos Reis)
- Subject: Re: rel_ops issues
- From: Joe Buck <jbuck at racerx dot synopsys dot com>
- Date: Sun, 1 Apr 2001 16:48:43 -0700 (PDT)
- Cc: Theodore dot Papadopoulo at sophia dot inria dot fr (Theodore Papadopoulo), libstdc++ at gcc dot gnu dot org
> | So, for what it worth, I second Joe in his demand to make
> | libstdc++-v3 more user friendly.
I did not ask for the library to be made more user friendly.
I asked for it to be made correct.
> I don't see what is so user friendly to break silently user code with
> std::rel_ops. Again, __normal_iterator is broken but std::rel_ops
> isn't the cure.
The cure for the conflict between __normal_iterator and std::rel_ops
is to create more specializations.
For example, create
template<typename _Iterator, typename _Container>
inline bool
operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
const __normal_iterator<_Iterator, _Container>& __rhs)
{ return !(__lhs == __rhs); }
and similarly for >, >=, and <=.
This eliminates the ambiguity between std::rel_ops::operator!=
(for the case where it is in scope) and the existing definition
of !=, that is
template<typename _IteratorL, typename _IteratorR, typename _Container>
inline bool
operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
const __normal_iterator<_IteratorR, _Container>& __rhs)
{ return !(__lhs == __rhs); }
The latter form will be selected only when the two iterators have
different type (a case that is not matched by std::rel_ops::operator=).
Because of the way partial specialization works, the more specific
definition wins.
Please understand: libstdc++-v3 is not releasable until this problem is
solved. I and others have lots of code that requires use of the rel_ops
and that uses the STL; such code compiles with aCC, Sun C++, MSVC, etc,
etc. It's not acceptable to blame the spec when it is a simply fixed bug.
> | By the way, I always thought that the headers like
> | map.h and friends were mandated by the standard with the meaning of
>
> Wrong.
Correct. However, there is a multi-compiler convention for them (see
Stroustrup's 3rd edition, the Dinkumware library, etc). If they are
provided, though, they should not say
using namespace std;
but rather they should export only the names defined in that header.
(Note: the issue of map.h is completely separate; the fact that
std::rel_ops conflicts with __normal_iterator is IMHO a release-critical
bug).