------- Additional Comments From gdr at integrable-solutions dot net
2005-08-12 11:45 -------
Subject: Re: can't compile self defined void distance(std::vector<T>,
std::vector<T>)
"adah at netstd dot com" <[EMAIL PROTECTED]> writes:
| > | For a class X, all functions, including free functions, that both
| > |
| > | * `mention' X
| > | * are `supplied with' X
| > |
| > | are logically part of X, because they form part of the interface of X.
| > That definition bans std::swap as currently usable
| > with std::complex<double>, e.g.
| > std::complex<double> w, z;
| > swap(z, w);
|
| Herb's opinion is that one should write `std::swap(...)'.
However it fails to scale to generic functions. "swap" has come close
to the status of "operator", needing no qualification.
| `Swap' is just an algorithm,
completely irrelevant to the issue under consideration.
| and has nothing to do with `complex' per se.
Wrong. The code as written above is written on purpose and has
well-defined behaviour. It can be generalized to well-defined and
well-behaved function. At this point, I suggest, again, that you go
back read the history of ADL and why it was introduced.
And, please refrain from reciting half-digested material.
| It is clearly stated in Section 4.3 of his proposal.
yes, but you chose to ignore that it is his proposal, not something
adopted by the C++ committee and my explicit note in previous message.
You cannot expect meaning discussion if you chose to selectively
ignore facts.
| > You would have hard-time convincing me that I want that behaviour for
| > standard C++, let alone GCC. Furtheremo more, you have to define
| > "supplied with". If N gives me
| > namespace N {
| > struct X { };
| > }
| > and M adds
| > namespace M {
| > using N::X;
| > f(X);
| > }
| > is M::f part of N::X's interface?
|
| I guess `No'.
Then your definition ot "interface" suddenly becomes useless.
| Herb's rationale is in C++ Coding Standards:
Rationales vary from people to people. If you want to discuss
standard C++ specified semantics and its implementation by GCC, you
have to come with something the C++ committee agrees on, otherwise
you're out of luck.
| 57. Keep a type and its nonmember function interface in the same namespace.
|
| Please differentiate between what I request and what we discuss.
You suggested to implement semantics according to "technical" meaning
of "interface". When pressed to give a precise meaning, you hide
yourself behind something else, claiming that it is different from
what you request. If you believe it is not what you advocate, then
keep it out and speak of what *you* advocate. Otherwise, you're just
continuing to annoy people who might otherwise be disposed to listen
to you.
| I did not advocate to implement Herb's proposal here.
Then keep it out. I'm NOT here just to discuss; it you want a chat room,
this is not the right place.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
