[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 14:02
---
(In reply to comment #99)
> "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, e.g.
> | >std::complex 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
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 10:50
---
(In reply to comment #97)
> Subject: Re: can't compile self defined void distance(std::vector,
std::vector)
> "adah at netstd dot com" <[EMAIL PROTECTED]> writes:
> | > you still fail to provide such a definition for "interface".
> | > -- Gaby
> |
> | Why should I?
> Because, it is *you* who brought that topic in this discussion.
> | Herb defined it in Exceptional C++, Item 32:
> |
> | 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, e.g.
>std::complex w, z;
>swap(z, w);
Herb's opinion is that one should write `std::swap(...)'. `Swap' is just an
algorithm, and has nothing to do with `complex' per se. It is clearly stated
in Section 4.3 of his proposal.
> 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'. Herb's rationale is in C++ Coding Standards:
57. Keep a type and its nonmember function interface in the same namespace.
Please differentiate between what I request and what we discuss. I did not
advocate to implement Herb's proposal here. At least not yet.
Best regards,
Yongwei
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 09:23 --- (In reply to comment #95) > | > | Herb Sutter's opinion (N1792) is a little different. He thinks that > | > | ADL should not work in the OP's example, because distance is simply > | > | not an `interface' of std::vector (technically, instead of from > | > | human eyes). But it is also self-consistent. > | > All those are assertions, little evidence. Notice that what is > | > considered an "interface" varies from one individual to another > | > individual. And we just don't have a definition for it, so you're > | > still using your "human eyes" definition, i.e. projection of your own > | > wishes. > | > | By `technical' I meant algorithmically recognizable. > you still fail to provide such a definition for "interface". > -- Gaby Why should I? Herb defined it in Exceptional C++, Item 32: 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. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 08:52
---
I am glad it is again normal discussions.
(In reply to comment #93)
> Subject: Re: can't compile self defined void distance(std::vector,
std::vector)
> "adah at netstd dot com" <[EMAIL PROTECTED]> writes:
> | Herb Sutter's opinion (N1792) is a little different. He thinks that
> | ADL should not work in the OP's example, because distance is simply
> | not an `interface' of std::vector (technically, instead of from
> | human eyes). But it is also self-consistent.
> All those are assertions, little evidence. Notice that what is
> considered an "interface" varies from one individual to another
> individual. And we just don't have a definition for it, so you're
> still using your "human eyes" definition, i.e. projection of your own
> wishes.
By `technical' I meant algorithmically recognizable.
> I was in the room when ADL was discussed at the last meeting in Norway
> -- and indeed, I was part of the people who fiercely encouraged Herb
> to bring forward "his modest proposal" (and that does not mean I agree
> with every word contained in the proposal, but my interest in getting
> the issue addressed). At that time, I was presenting possible ways
> the concept proposal may reduce the uncontrolled power of ADL. I have
> suggested that you give a try to the exercise of "name lookup". That
> suggestion still holds. Untill, you have done so it is almost certain
> then you will completely miss its the depth and ramifications. It is
> no Herb's opinion against mine. It is a matter of precisely and
> consistently defining the rules so that the most common cases are
> gotten right. No, it is not GCC's job. Furthermore, if you want to
> eliminate ADL effects; you have to break existing codes and ban ADL.
> Herb's suggestion already breaks some existing reasonable codes -- and he
> acknowledges that. You can argue from your notion of engineering and
> intuition, but that is all. And you have to have everbody else's
> notion of engineering and intuition intersect with your before moving.
> Once, the rules get written and ADL isstill supported, one will always
> find cases that is considered either "intuitively and obviously
> correct" or "intuitively and obviously wrong". The reason is very
> simple: ADL was *designed on purpose* to make overload set across separate
> scopes -- something which did not exist before. Once you're given
> that, all bets are off. The only thing you can do is to work to get
> what you consider to be the most common cases "intuitively and
> obviously right". And live with the rest.
These statements I agree. You enlightened me that there are more than one way
to go to make the OP's code work, and Wolfgang showed that my opinion might be
practically difficult to implement. Thanks for that.
Please note I mentioned Herb's proposal only to reply to Wolfgang. I never
said, not even hinted, that it should be implemented in GCC now.
> [...]
> | it is safer to have a better diagnostice message *now*.
> you get a better diagnostic when you can precisely spell out what
> alternate rules can be or give a precise consistent algorithms. You
> haven't so far. Just arguing.
Has a user to be a compiler writer to give enhancement suggestions, I wonder?
Though you may still think it is not an algorithm, I am trying again (in Gene
Bushuyev's way):
Function overload_resolution(function_name, arguments,
current_namespace, function_namespace)
{
set overload_set;
set failed_set;
for (Function function = parse_tree.functions.begin();
function != parse_tree.functions.end(); ++function)
if (function->name == function_name
&& function->check_lookup_rules(current_namespace, function_namespace))
{
if (function->is_a_template())
{
try
{
if (!function->is_explicitly_specialized())
template_arguments = function
->deduce_template_arguments(arguments); // 14.8.2
instance = function->instantiate(template_arguments) // 14.7.1
overload_set.insert(instance); // 14.8.3/1
}
catch (const SubstitutionFailure&)
{
failed_set.insert(*function); // only for reporting purposes
// do nothing with this candidate according to 14.8.3/1
}
catch (InstantiationFailure& e)
{
e.add_instantiation_failure_point(*function);
if (is_unqualified(function_namespace
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 05:12
---
I am not sure whether we can finish here (not to challenge you, but that I am
still a little misunderstood). See below (for pure technical discussions, and
just to reply to you).
(In reply to comment #90)
> While I sympathize with your desire to have a better error message, you seem
> not to understand the implications of what you ask us to do. First, ADL
On the contrary, I do.
> (Koenig lookup) is meant particularly to allow separation of names into
> different namespaces, even though it allows for lookup of names across
> namespaces. Consider this example:
[Example snipped]
> In this example, you definitely do want ADL to work as it is supposed to,
> but in the example used in this PR you don't. That's not consistent. It
It is consistent.
What I thought when I entered the discussion here was that ADL should work but
the instantiation error should remove it from the candidate list (e.g. to
extend SFINAE). So I did think ADL worked here, and there was no consistency.
Herb Sutter's opinion (N1792) is a little different. He thinks that ADL should
not work in the OP's example, because distance is simply not an `interface' of
std::vector (technically, instead of from human eyes). But it is also self-
consistent.
> would also not be very helpful to print a warning message to the screen
> saying "hey, you may have wanted std::swap, but I picked User::swap anyway",
> which would be the exact opposite of what you would want in the case you
> present in this PR.
This was not what I used to want. But since I learnt that the future was still
undecided which way the committe would take to solve this issue, it is safer to
have a better diagnostice message *now*.
> So your second solution was to ask that functions that don't compile properly
> to simply be dropped from name lookup. Now, that's getting really messy:
> ---
> int f(int i) {
> do_something();
> // oops, forgot return value -- compiler error
> }
>
> int g(int i) {
> return f(i);
> }
>
> int h(int i) {
> return g(i);
> }
>
> int h(double) {
> return 1;
> }
>
> int main () {
> h(1);
> }
> --
> What the user clearly wanted was to call h(int). However, h(int) calls a
> function that has a user error -- oops. So f() and g() don't compile, should
> h(int) be dropped from the overload list (without an error, as per your
> suggestion), and h(double) be used with the standard conversion of the
> argument '1' from int to double?
This can be a valid point. Practically it is a little difficult to
differentiate an instantiation error from a program error.
Though, Sutter's suggestion is still a way to go.
> So, in neither case is changing the rules of the language a very good choice,
> which is exactly why Gaby and I claim that there is no defect in the
standard:
> everything else one could possible come up with is even more completely
> ununderstandable.
I think the above discussion is enough and I do not need to add comments
here? :-)
> I hope this explains why we don't want to change the compiler to do something
> different than what the standard prescribes -- because we're reasonably sure
> that the standard wouldn't follow our precedent and we'd be eternally
> incompatible after that.
>
> The question remains whether we can do anything about the weird error message
> one gets with code like yours. That it isn't very helpful is completely
> undisputed, but that doesn't mean that anyone has an idea of how to improve
> it.
I stated long ago (several days indeed) that this could be of lower priority,
but it needs to be agreed on and added to a to-do list. Before your message I
had not seen a single agreement, but only flames.
> W.
Yongwei
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 03:47 --- (In reply to comment #86) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | What I have not is that a PRoblem resulting from an deficiency of the C++ > | Standard is not considered a PRoblem. > This is where it is obvious that Yongwei is trying to play Illiterate. > Because what I wrote was > # Furthermore, and more importantly, GCC bugzilla is the not the place > # to record UNEXPECTED or PROBLEM with the C++ standard. > > -- Gaby You were blinded by your anger. I sought a `guideline of GCC Bugzilla'. I did not think your words represent a `guideline of GCC Bugzilla'. Sorry. If you do, please put `a problem resulting from an deficiency of the C++ Standard is not considered a problem' to an official page. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 03:00 --- (In reply to comment #84) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > On Aug 11, 2005, at 10:32 PM, adah at netstd dot com wrote: > > What I have not is that a PRoblem resulting from an deficiency of the > > C++ > > Standard is not considered a PRoblem. It is clear that many C++ gurus > > do think > > it a deficiency of the C++ Standard. > Yes but you said using GCC bugzilla for deficiencies in C++. GCC > bugzilla is not > for that but only for GCC deficiencies so if the C++ standard says one > thing and > you disagree with it, GCC bugzilla is not correct place to raise the > issue, even > if many "C++ gurus" says this is a bug in GCC, you should get a > clarification > from the standards committee which is not hard as DR reports are open > to anyone > and not limited to committee members. > -- Pinski Arguing for the principles is difficult, if the one point we disagree is not explicitly listed officially somewhere (I am not convinced unless I see a statement like that GCC wants to be a bug-for-bug translator of the C++ Standard). So I am not to argue with you. :-) Please understand that my reason to post comments here was not because this was a C++ problem, but because I hoped the behaviour of GCC in this aspect could be better. And I want to say that IMO it was a little premature to mark this bug as `REJECT-INVALID': `SUSPEND' is much better (I admit the state change irritated me a little, and my bitter quarrel with Gaby somehow began there). When the WG21 has decided this *is* a bug of the Standard, you will then reopen the bug again? I simply do not think it a good idea to stick to every exact word of the Standard (it will change after all). Admittedly it is only my personal opinion. Even if you cannot agree with a word of all stated above, I suppose I am still allowed to request to improve the error message so that a user can recognize *WHAT* is going wrong and *WHERE*. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 02:32 --- (In reply to comment #82) > > Show an official page. > http://gcc.gnu.org/bugs.html > "In particular, bugs caused by invalid code have a simple work-around: fix the code." > "With each release, we try to make G++ conform closer to the ISO C++ standard (available at http://www.ncits.org/cplusplus.htm). We have also implemented some of the core and library defect reports (available at http://www.open- std.org/jtc1/sc22/wg21/docs/cwg_defects.html & http://www.open- std.org/jtc1/sc22/wg21/docs/lwg-defects.html respectively)." > http://gcc.gnu.org/gcc-3.4/changes.html > "GCC 3.4 has many improvements in the C++ frontend. Before reporting a bug, please make sure it's really GCC, and not your code, that is broken." > There are more. > -- Pinski Thanks, Pinski. These I have read. What I have not is that a PRoblem resulting from an deficiency of the C++ Standard is not considered a PRoblem. It is clear that many C++ gurus do think it a deficiency of the C++ Standard. And it is arguable whether the OP's code is broken or not. But this is not what I want to argue here. My current request is exactly to tell the user that his code might be broken (unspecified and non-portable) under the current C++ Standard. I do not think it is against any rule of the GCC community. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-12 02:10 --- (In reply to comment #79) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > > | > Furthermore, and more importantly, GCC bugzilla is the not the place > | > to record UNEXPECTED or PROBLEM with the C++ standard. > | > | Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is > | never considered a PRoblem at all? > > Ahem. Can you read? Show an official page. > | If it is, please show me where I can read it. > I'm very willing to do so if you provide evidence that you can read. The only thing I can say is that you are an absolutely incurably rude person. > | should be output. If this function is in some namespace and the original > | function call is not qualified, then an additional warning on argument- > | dependent lookup should be emitted. > | > | Simple rules. I do not think it is magic. > Surely, your rules do not require magic. They just appear nonsensical to > me. As argument dependent name lookup has become an essential part of > C++ libraries, begining the standard one. I do not invalidate ADL. Just that ADL is causing problems, and some diagnostic messages (only when problems occur) can help people encountering these problems identify their problems. Not only I am saying that ADL is causing unwanted problems. I do not think Herb Sutter's opinion that the OP's program *should* compile is less authentic than yours. > | No. If I put it simply, then this behaviour violates the rationale of > | namespaces. > Which rationale? Name separation. People can use names freely (in their own namespace or the global namespace) without worrying that the name is used in another namespace. > | This is not the behaviour I am currently requesting. I just wanted to told > | Wolfgang there is a third way to `fix' the problem which I prefer better than > | his suggestions. > Essentially, you're here just to argue. I am afraid that it is YOU that are here to argue, and to *flame*. > -- Gaby Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-11 03:51 --- Hi Gaby, I have read Sutter's Modest Proposal on fixing ADL that you referred to me. If you had told me earlier about this instead of bluntly telling me this was not a GCC bug, I would have much more quickly given up the request to `fix' this behaviour. (Hey, PLEASE do not argue with me on this: it is just an after comment on facts.) Since the future is undecided on how to make the program pass (I believe it *is* the consensus of C++ gurus that the OP's program should compile, though it is undefined and nonportable under the current C++ Standard), it is premature to take measures to `correct' the current behaviour. However, the error message *is* user unfriendly. I suppose no one objects to this. So my request is still that the error message should be improved. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-11 02:01 --- (In reply to comment #76) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | Now to your point. Please notice that my current stance is not that > | GCC should fix this `bug'. I have stated it days ago. But the > | user's failure is really UNEXPECTED, and this is a PROBLEM. > Please, do consider that the outcome of this is the specification of > "argument dependent name lookup". It is the same rules that apply > whether the function is called "distance" or "freebies" and the > namespace is called "std" or "foobar". Just saying, "ah, this is std, > therefore the outcome is unexpected" is not sufficient. To > appreciate the issue and argue you NEED to understand the rules. > Furthermore, and more importantly, GCC bugzilla is the not the place > to record UNEXPECTED or PROBLEM with the C++ standard. Is it a guideline of GCC Bugzilla that a PRoblem owing to the C++ Standard is never considered a PRoblem at all? If it is, please show me where I can read it. > | To avoid this problem, a better diagnostic message should be > | emitted. Just try compiling the OP's program to see my point. > Just consider how you would formulate the rules for name lookup to > appreciate the point people are making here. There is no magic. We > don't have the keyword "readmymind". If the instantiation of a function (its body or its return type, arguments, etc.) fails during overload resolution, then the complete name of the function should be output. If this function is in some namespace and the original function call is not qualified, then an additional warning on argument- dependent lookup should be emitted. Simple rules. I do not think it is magic. Just that some contexts need to be remembered. > [...] > | I cannot help wondering why (though this might be better discussed > | on comp.std.c++: I do hope you can discuss there). IMHO, the > | current bahaviour is violating the rationale of the std namespace. > You seem to focuse on namespace std, without understanding that this > issue has nothing particular to do with std. Would have the issue > have been different if the namespace was called std? If you think > yes, then I suggest you give it more thoughts. No. If I put it simply, then this behaviour violates the rationale of namespaces. Please notice that I always consider it a problem in the C++ compiler (nothing to do with one specific namespace) instead of libstdc++. Again I can say yes. This problem is most likely encountered by a user using the std namespace. Logically, `violates the rationale of the std namespace' does not contradict `violates the rationale of namespaces'. However, on this point you are basically right. I should have expressed better. > [...] > | c) Failure to instantiate a template function should automatically remove it > | from the candidates of overload resolution. > If you want to modify standard rules, please, again take it to the > committee in charge of C++. > -- Gaby This is not the behaviour I am currently requesting. I just wanted to told Wolfgang there is a third way to `fix' the problem which I prefer better than his suggestions. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-10 04:31 --- The error message I am imagining (not sure of its feasibility): .../stl_iterator_base_types.h: In instantiation of `std::iterator_traits > >': .../stl_iterator_funcs.h: In instantiation of (return type of?) `std::distance (std::vector, std::vector' (as found by argument-dependent lookup: use a scope modifier like `::' if this is not what you want): test1.cpp:32: instantiated from here ... Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-10 03:34 --- (In reply to comment #73) > > encountered the problem before. Not to say understand the problem. As the > > very beginning, adding a message like `In instantiation of std::distance...' > > will be helpful. > But it is not instantiating std::distance just yet, it is looking at the return values/parameter types. But it is about to instantiate std::distance, right? Even if not right, my point is still that one should notified of the existence of std::distance somehow. > ICC produces about the same error message: > /opt/intel/include/c++/xutility(290): error: class "std::vector>" has no > member "iterator_category" > typedef typename _Iter::iterator_category iterator_category; > ^ > detected during instantiation of class "std::iterator_traits<_Iter> [with _Iter=std::vector std::allocator>]" at line 12 of "t.cc" > compilation aborted for t.cc (code 2) Do you think this message is helpful for a user that encounters this problem? That is just one place to show that GCC can do better than commercial compilers. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-10 03:11 --- (In reply to comment #71) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > On Aug 9, 2005, at 10:41 PM, adah at netstd dot com wrote: > > > > Passing this information to the user is difficult, unless GCC emits a > > diagnostic message to help users do so, as GCC is currently doing on > > the > > missing of `typename'. > even then as I said before when it comes down to it, nobody reads those > messages as they think their code is correct. > See my example when sequence points, we do warn about it in 4.0.0 and > above > (for C++; for C, we have warned since at least 3.0.4) and people still > file bugs. > Another example of where people don't read is the changes page, which > describes > changes to the compiler which could hinder (or benefit) them. One > example is > the change in the namelookup for templates to be more towards the > standard. That > example shows that we still get bug reports so even with a better error > message, > people will have something to complain about. > -- Pinski It is regretful that many people cannot read. But many people *can* read. Converting from GCC 2 to GCC 3 made my code much more conformant to the C++ standard, owing to the messages like that of `typename'. And the messages emitted by a compiler are read more often than something in a doc page. The main problem of the current error message is that it even mentions nothing about std::distance. So even an experienced programmer can have difficulty finding out the problem if he does not know std::distance and has not encountered the problem before. Not to say understand the problem. As the very beginning, adding a message like `In instantiation of std::distance...' will be helpful. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-10 02:40 --- Since I do not think I can find appropriate words to respond to Gaby without inflaming the discussion, I think I had better suppress my will to argue with him it for the moment. Not that I want to ignore his messages. On the contrary, I have read every word. Sorry that I had ignored some of his advice before. Some was useful. Regret that I am not an expert in the C++ Standard, as most C++ users are not. (In reply to comment #66) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > > This is reasonable. That was why I thought it was not necessary to `fix' this > > bug after some discussions. I just thought it was still a bug, and some > > measures need to be taken to warn the user about this problem. It might be of > > low priority, but simply marking it as `INVALID' just covers this problem. > > More people might discover this bug again and report it again, though they > > might not be as _ (fill in adjectives that you like) as I am. > Even documentioning what the standard say in the non bug section of bug reporting > web page, does not help people to read the docs. There is no way really to fix > this. Look at the sequence point docs in bug reporting web page and then look at > all the dupicate bugs. > -- Pinski Now to your point. Please notice that my current stance is not that GCC should fix this `bug'. I have stated it days ago. But the user's failure is really UNEXPECTED, and this is a PROBLEM. To avoid this problem, a better diagnostic message should be emitted. Just try compiling the OP's program to see my point. My bug report was a duplicate too, but I did do a search on `Koenig'. I did not search on `distance' because I did not think it was the point. (In reply to comment #67) > I think we should all recuse ourselves from this discussion, since we just > keep iterating our same old positions: > > Yongwei believes that this is a defect in the standard and that gcc should > not follow the standard in this respect. > > Gaby and I believe that gcc should follow the standard, and probably both > believe that the standard does not have a defect in this respect. We believe I cannot help wondering why (though this might be better discussed on comp.std.c++: I do hope you can discuss there). IMHO, the current bahaviour is violating the rationale of the std namespace. > that changing the standard would require a massive change in the language, > since it would either a) require the introduction of concepts (so that > std::distance can only be called with arguments that match the concept > of an iterator; same for all other similar functions), or b) abandoning > argument dependent (Koenig) name lookup. Neither sounds like an appealing If this bug should ever be fixed, I would prefer this approach: c) Failure to instantiate a template function should automatically remove it from the candidates of overload resolution. > idea. We believe that users can work around this perceived problem by > simply calling > ::distance (arg1, arg2) > to get to their own implementation, not the one in std:: Passing this information to the user is difficult, unless GCC emits a diagnostic message to help users do so, as GCC is currently doing on the missing of `typename'. > Since we can't seem to find an agreement, let's just leave it at that. > > W. I am not an unreasonable person. I just want to see a reasonable ending. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-09 13:36 --- (In reply to comment #58) > It serves its users by providing a reliable translator for the language > defined by the standard. Think about the portability implications of > compilers that willy-nilly implement some parts of the standard but not > all, based on what they perceive as their users' best interest. Generally you are right. However, people that encounter this bug most probably know little (if any) of the C++ Standard (and thus care little about conformance to the Standard), and people know well about the Standard most probably won't encounter this bug at all. So I do not think this point really holds. > If you go beyond toy projects, then best user interest will place a formally > and well-defined, portable language over a language that always does what > the user intuitively wants it to do. This is reasonable. That was why I thought it was not necessary to `fix' this bug after some discussions. I just thought it was still a bug, and some measures need to be taken to warn the user about this problem. It might be of low priority, but simply marking it as `INVALID' just covers this problem. More people might discover this bug again and report it again, though they might not be as _ (fill in adjectives that you like) as I am. > > W. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-09 13:26 --- (In reply to comment #63) > | Do *you* like it? > It is immaterial as far as GCC is concerned. I know where to raise Why immaterial? I just cannot imagine anybody that *likes* this behaviour. If no one likes it, how can you call it reasonable behaviour (just because a C++ god nodded)? If it is not reasonable behaviour, why can't you accept that it is a bug? By the way, I think a `bug' here can really be a design flaw, or an enhancement request. > such issues and I've suggested you do the same. You seem not to > understand that comp.lang.c++.moderated and comp.std.c++ are the I posted about one day ago on comp.std.c++. No one answered. I do not know any better way to contact anybody that might be in the committee. > appropriate places. Insisting here will not help you. At this point, Reproaching me in this way won't help you, either. I repeat one thing: I do not have the OP's problem. As a programmer that has some familiarity with the language and the Standard, it is hard to encounter this kind of problems. --- People that encounter this bug most probably know little (if any) of the C++ Standard, and people know well about the Standard most probably won't encounter this bug at all. --- This fact strengthens my point that it is a bug. > the only thing you're doing here is sabotaging your own cause by > frustrating people, who otherwise might be disposed to listen to and If you had not spoken in this kind of tones, I might have been much more considerate and constructive. However, I have already tried to be calm and constructive instead of being flamy. I just cannot understand why you have never shown any patience and sympathy on this issue. > support you. If that was your original purpose, then you have > partially succeeded. > -- Gaby Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-09 10:49 --- (In reply to comment #61) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | --- Additional Comments From adah at netstd dot com 2005-08-09 01:45 -- - > | (In reply to comment #59) > | > Subject: Re: can't compile self defined void distance(std::vector, > | std::vector) > | > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | > | Does a compiler serve its users or the Standard committee? > | > Answer: Does a compiler that does not implement the standard specification > | > serves its users? > | > -- Gaby > | > | Answer to answer: Does a compiler that implement a wrong specification in the > | Standard serves the users? > The core issue is how do you determine that a standard specification > is wrong? Just because *you* don't like it? Sorry, that is insufficient. Do *you* like it? If you like it, then I suppose you like to frustrate GCC users? > There is a well-known body and a well-known process to handle that. > Please take it to the C++ standard committee. Common users are not supposed to talk with the standard committee. They may even not know it. I have stated it clearly enough. > | I am not requiring that GCC must fix the bug > Bugzilla is about bugs in GCC. If you think it is not a bug, then you I do think it is a bug (also clear enough, as I still call it a `bug'). Even though it might be due to a bug in the Standard. > must take it to the place where they handle perceived bugs in the standard. > -- Gaby Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-09 01:45 --- (In reply to comment #59) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | Does a compiler serve its users or the Standard committee? > Answer: Does a compiler that does not implement the standard specification > serves its users? > -- Gaby Answer to answer: Does a compiler that implement a wrong specification in the Standard serves the users? A bug in the Standard does not prevent a bug in the compiler from being a bug! I am not requiring that GCC must fix the bug (I do not want to argue here endlessly as well), but I am dissatisfied that you do not think it a bug. Just imagine the complete loss of an innocent user that happens to define a distance (vector<...>,...) (`I can name my global functions as I like, or what is the purpose of the std namespace?'), when the error messages seem to show that the compiler is talking nonsense! BTW, I do not think a common user has channels to talk to the Standard committee. Compiler vendors have. My opinion is that the bug should be `suspended' or `deferred', while displaying a more friendly error message should be added to the to-do list of GCC. Best regards, Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-08 12:56 --- (In reply to comment #56) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | (In reply to comment #53) > | > I know no one named Paul M. He seems not here, either. > | > | Really sorry that I missed the latest posting on comp.lang.c++.moderated by > | Paul Mensonides > | > | The explanation is good enough. The result is bad enough. > As suggested in the very beginning, if you don't like the result take > it to the C++ committee. That is the appropriate place to discuss > standard specifications wrong with respect to user's point of view. > -- Gaby While I fully respect the labours of the Standard committee, and have come to realize the potential technical difficulties in this issue, you words leave me to wonder: Does a compiler serve its users or the Standard committee? Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-08 06:31 --- (In reply to comment #53) > I know no one named Paul M. He seems not here, either. Really sorry that I missed the latest posting on comp.lang.c++.moderated by Paul Mensonides The explanation is good enough. The result is bad enough. The error message will make STL even more notorious. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-08 06:19 --- (In reply to comment #52) > Subject: Re: can't compile self defined void distance(std::vector, std::vector) > "adah at netstd dot com" <[EMAIL PROTECTED]> writes: > | This said, I still cannot think this bug report is `INVALID', from a user's > | point of view. > We're dealing with INVALID as whether it is a bug with respect to the > language standard. > [...] I have not yet been able to deduce from the Standard that the OP's code is invalid. > | The instantiation is done after the `template argument deduction' is > | successful. > Have you read Paul M.'s explanation? I know no one named Paul M. He seems not here, either. > -- Gaby Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-08 03:53 --- Sorry for the tone in my previous comment. I guess I was a little heated and acted in a haste. This said, I still cannot think this bug report is `INVALID', from a user's point of view. The test code showed it clearly enough. However, this time let me try to see whether my point can find grounds in the current C++ Standard: 14.8.3/1: `When a call to that name is written (explicitly, or implicitly using the operator notation), template argument deduction (14.8.2) and checking of any explicit template arguments (14.3) are performed for each function template to find the template argument values (if any) that can be used with that function template to instantiate a function template specialization that can be invoked with the call arguments. For each function template, if the argument deduction and checking succeeds, the template-arguments (deduced and/or explicit) are used to instantiate a single function template specialization which is added to the candidate functions set to be used in overload resolution. If, for a given function template, argument deduction fails, no such function is added to the set of candidate functions for that template.' The instantiation is done after the `template argument deduction' is successful. Note it is `template argument deduction' but not `function argument deduction'. I fail to see why the return value type is not considered in the template argument deduction, though the Standard is somehow a little vague on this (I have found no explicit requirements or prohibitions.) By the way, the current error message for the instantiation failure is not helpful at all to help the user identify the problem! Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-08 02:26
---
Sorry, but some of you here have not read carefully enough and acted in a
haste. Please test with the following code piece and make a decision AFTER
that:
#include
#include
int distance(std::vector v1, std::vector v2)
{
std::cout << "I am chosen!" << std::endl;
return v1.size() - v2.size();
}
// Begins the hack
namespace std {
template<>
struct iterator_traits >
{
typedef int iterator_category;
typedef int value_type;
typedef int difference_type;
typedef int distance_type;
typedef int pointer;
typedef int reference;
};
}
// End the hack
int main()
{
std::vector v1(3), v2(1);
int d = distance(v1, v2);
return 0;
}
The point is: adding the seemingly unrelated code will make the user distance
be chosen.
Best regards,
Yongwei
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-05 05:41 --- (In reply to comment #44) > | However, I still believe it is the problem of the compilers. > Please take ti to the C++ standard committee. The behaviour is that > described by the standard. If you don't like it, have the committee The behaviour I wanted is at least not *against* the standard, while being more natural and user-friendly. As James Kanze quoted ยง14.7.1/5 in comp.lang.c++.moderated: "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." BTW, proposal N1799 directly addresses this problem and, if adopted, will make the program we are discussing legal instead of unspecified behaviour. > change it. If you think name lookup is an easy exercise, give it a try. I never thought any part of a C++ compiler is easy. I just try to express my opinions on this subject, as a common gcc user (I myself do *not* define any functions named distance). > -- Gaby Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-04 05:27 --- As the reporter of Bug 23213, I want to add my 2 cents (my opinions): 1) This bug is not in libstdc++, but in the C++ compiler. 2) The std::distance (as found by Koenig lookup) does not hide the global one the user defines, but the failure to complete the return type aborts the candidate building procedure (if we fake the type definitions required, the user-defined version will be correctly selected). And SFINAE does not kick in. I really cannot see why this is not a bug (providing something unrelated to user code will make the user code work!). 3) To complicate the matter, all "good" compilers I know fail in this case. However, I still believe it is the problem of the compilers. Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug c++/23213] New: Error in Koenig Lookup causes overload resolution failure
http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thread/3c449572456c8592
The test program:
#include
int distance(std::vector v1, std::vector v2)
{
return v1.size() - v2.size();
}
int main()
{
std::vector v1(3), v2(1);
int d = distance(v1, v2);
return 0;
}
The error message from 3.4.4:
D:/mingw-gcc3.4/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.4.4/bits/stl_iterator_base_types.h:
In instantiation of `std::iterator_traits
> >':
test1.cpp:11: instantiated from here
D:/mingw-gcc3.4/bin/../lib/gcc/mingw32/3.4.4/../../../../include/c++/3.4.4/bits/stl_iterator_base_types.h:129:
error: no type named `iterator_category' in `class std::vector >'
It has been confirmed that the problem is not that Koenig lookup takes priority
over the local overload, etc. It is that the failure to deduce the return type
of the instantiation of std::distance<>() caused the abortion of candidate
building. If the necessary typedef is provided, the local version of distance
will be correctly selected.
It might be arguable whether SFINAE should be applied here (the C++ standard is
not quite clear on this). But I do not think it the purpose of the standard to
let something in the std namespace affect local name resolution. Maybe you
gurus here can judge better?
This problem occurs from 2.95.3 to 3.4.4. I believe it is platform-independent.
--
Summary: Error in Koenig Lookup causes overload resolution
failure
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adah at netstd dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23213
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From adah at netstd dot com 2005-04-18 09:06 --- Function calls, memory barriers, (and "lock" operations?) are all overheads. I would like that * GCC provide extensions so that GCC users can use memory barriers and threading calls in a platform-independent way, and * - Revert the patch, or at least - Provide a command-line option (or pragma/attribute?) to disable/enable static initialization protection. With the former, users can implement the protection as efficiently as the compiler can (correct me if I am wrong). With the latter, the new GCC is still usable in some applications that require performance no less than C. I am really worried that with the improvements introduced to GCC beginning with GCC 3, some of my applications are running slower and slower, though some problems only show up on Windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From adah at netstd dot com 2005-02-03 03:42 --- I want to emphasize here again one principle of C and C++: Trust the programmers, and allow them to do low-level tunings for performance. Or what is the purpose of C++ (when compared with "high-level" languages like Python)? This "fix" rid the programmers of their right to choose the way they want. Unless the future C++ standard demands protection in such cases, I do not think the compiler-provided mechanism a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From adah at netstd dot com 2005-02-03 03:30 --- I am not David but let me try to name some possible objections. * The current code is unsafe on some architectures (DLCP is unsafe) * For cross-compiler code, users SHOULD have already locked a mutex before entering the function that might have race conditions: so there will be unnecessary overhead * If users do not use a mutex, if might well be the case that the specific function will be called by only one thread; or that the function has been called at least once in the initialization (one thread only) code; and the "fix" creates unnecessary overhead again Granted, there is no standard C++ API for threading. But when users write a multi-threaded program, they have already begun to use non-standard threading APIs. They might well use the APIs to protect what this fix tries to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
