This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)


------- Additional Comments From adah at netstd dot com  2005-08-12 14:02 -------
(In reply to comment #99)
> "adah at netstd dot com" <gcc-bugzilla@gcc.gnu.org> 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. 

Give evidence.

I am on Herb's side that there is no evident reason to use `swap' on standard
types while using `std::swap' on user types.

> | `Swap' is just an algorithm,
> 
> completely irrelevant to the issue under consideration.

Give the reason why it is irrelevant.

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

Things are not wrong just because you said it was wrong.  Give evidence.

> And, please refrain from reciting half-digested material.

Please refrain from giving immature comments.

> | 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 chose to talk about his proposal, not I.  My sole purpose to mention his
proposal was to show to Wolfgang that there are two `consistent' ways dealing
with ADL.  Consistency was the thing we focused on.

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

His rationale is consistent with his proposal how to change the wording in the
Standard.  Technically it is clear how to apply his principles to choose which
functions his modified ADL should find.

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

I was replying to Wolfgang, as I said above.  Even in that message I did not
advocate it.  In all recent messages the only thing I advocated is the
improvement of the error message, and how.

Sorry I am afraid it is you that cannot read.

> -- Gaby

Yongwei

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910


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