This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: rel_ops issues



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]