This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: rel_ops issues
- To: Joe Buck <jbuck at racerx dot synopsys dot com>
- Subject: Re: rel_ops issues
- From: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Date: 02 Apr 2001 06:47:59 +0200
- Cc: Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr (Gabriel Dos Reis), libstdc++ at gcc dot gnu dot org
- Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
- References: <200104020002.RAA00644@racerx.synopsys.com>
Joe Buck <jbuck@racerx.synopsys.com> writes:
[...]
| However, if the user brings them into the global namespace with a
| using directive, it is not permissible for the STL to completely break.
The point is that we recommend user not to bring std::rel_ops contents
in scope. That is that simple. The library can't fix users' broken
code.
[...]
| > | using std::rel_ops::operator!=;
| > |
| > | and also use STL classes must work.
| >
| > Programs which say that incantation deliberately choose to break --
| > the library has no business to fix that. Sorry.
|
| Clearly you don't have an adequate understanding of partial
| specialization. (Please be clear: I'm confident that you understand
| it as a compiler developer. But you lack understanding of how to use
| it as a library designer, or you would have fixed this problem in five
| minutes).
Before questioning my understanding of function templates and how to
use them in real world libraries, you might to learn more about them,
what is there and what isn't there.
| With a proper library, the only programs that can ever be broken by
| importing std::rel_ops are programs where some class defines operators
| !=, ==, >=, or <= to not have the mathematical relationship with
| == and < defined by the rel_ops operators, or where they return non-bool.
Library designers have known for a long time that std::rel_ops should
not be considered.
| If you are convinced that the compiler is allowed to barf on programs that
| import rel_ops, please write to Bjarne and tell him to change many of the
| examples in his book.
And you might also want to carefully consider what he wrote.
As an aside, what is good to write to explain a specific topic in a
book isn't necessary good to copy religiously in a real world library.
And finally, the problem isn't really that of function overloading,
the problem stems from how name lookup works.
Again, __normal_iterator needs tobe corrected, but solutions
mentioning std::rel_ops are just that: wrong.
[...]
| just within one function. If you refuse to do that in cases like
| std::equal, then your only other choice is to replace the != by
| something like
| !(*a++ == *b++)
I prefer the latter.
-- Gaby