http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #12 from Paolo Carlini 2011-09-29
09:23:36 UTC ---
Ah, point taken about the irrelevance of the defect for this specific PR, sorry
for bothering. Yesterday I didn't even try to reconstruct how the discussion
had evolved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #11 from Johannes Schaub
2011-09-29 06:14:32 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > Excellent, then could you possibly comment on the implication for this PR?
> > (for
> > you it's easy, I'm sure)
>
...
> P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #10 from Johannes Schaub
2011-09-29 06:10:26 UTC ---
(In reply to comment #9)
> Excellent, then could you possibly comment on the implication for this PR?
> (for
> you it's easy, I'm sure)
Hi, wanna chime in here. It has no implicat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #9 from Paolo Carlini 2011-09-28
21:48:08 UTC ---
Excellent, then could you possibly comment on the implication for this PR? (for
you it's easy, I'm sure)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #8 from Daniel Krügler
2011-09-28 21:36:53 UTC ---
(In reply to comment #7)
> What happened to issue Core/983?
It was originally accepted but later found out to be the wrong solution,
therefore it became fixed again by CWG 1121.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org |daniel.kruegler at
|
--- Comment #6 from schaub-johannes at web dot de 2010-04-02 14:02 ---
(In reply to comment #4)
> Thanks for pointing out that this has changed since C++03, though the change
> was to fix to something that was clearly broken.
>
> In any case, I disagree with issue 983. The point of the
--- Comment #5 from schaub-johannes at web dot de 2010-02-11 15:06 ---
Ah, i see now. I always thought the the member pointer would contain an offset
from the nested-name-specifier of the "D::i" regardless of the type of the
result.
In fact, i see now that i'm wrong. Ambiguity checks a
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-11 05:29 ---
Thanks for pointing out that this has changed since C++03, though the change
was to fix to something that was clearly broken.
In any case, I disagree with issue 983. The point of the example is that it
doesn't matter
--- Comment #3 from schaub-johannes at web dot de 2010-02-11 01:08 ---
Well this is certainly not valid C++03, so i have tagged it c++0x (class member
name lookup was completely rewritten in c++0x, which made it valid and which
also added 10.2). In '03, the following should fail i think,
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-09 22:28 ---
Confirmed. 10.3 says that the lookup is unambiguous, just some uses can be
ambiguous. In fact, we fail the test in paragraph 13:
struct B1 {
void f();
static void f(int);
int i;
};
struct B2 {
void f(double)
11 matches
Mail list logo
