[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #10 from Johannes Schaub schaub.johannes at googlemail dot com
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 implication on my original PR (I'm not
taking a pointer to member), and has no implication on the example code Jason
quoted from the draft (so CWG983 was just noise -.-). Perhaps it's useful to
show more examples:
struct A {
int a;
};
struct B : A { };
struct C : A { };
struct D : B, C { };
struct E : D {
// valid, refers to one declaration
using D::a;
};
The above is valid in C++0x, and invalid in C++03. Certain uses of the alias
name E::a are valid, while others are invalid (those that check subobject
affinity)
decltype(E::a) x; // valid
int x = E().a; // invalid
See WMM's paper at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1543.pdf and the
usenet discussion at
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/4ae640b13b0bd334/
.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #11 from Johannes Schaub schaub.johannes at googlemail dot com
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)
...
Perhaps it's useful to show more examples:
struct A {
int a;
};
struct B : A { };
struct C : A { };
struct D : B, C { };
struct E : D {
// valid, refers to one declaration
using D::a;
};
Fail, I forgot I showed the same example above already :) Please forgive.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 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.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |daniel.kruegler at ||googlemail dot com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-28 21:31:35 UTC --- What happened to issue Core/983?
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 --- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com 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.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 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)
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- 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 example is that it doesn't matter what subobject it refers to, as the type of D::i is 'int B::*'. I notified Daniel Kruegler about this, since the DR got CD2 status. He replied that you might want to consider reopening it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- 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 are done for both of .* and for the implicit conversion at point of use, and the pointer will just contain offset 0 in B1 or something to that effect. I feel sad now since i'm guilty of making that issue report. Hopefully it won't make it into the IS :) Tho i wish they would make a cross reference to the section of .* (5.5) too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- 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, instead of
re-declaring the member name as an alias to the declaration of a in A:
struct A { int a; };
struct B : A {};
struct C : A {};
struct D : B, C { };
struct E : D { using D::a; };
The example in 10.2/13 (n3000) is missing an ambiguity check: It's impossible
for GCC to figure out to which sub-object the member pointer address is
associated with. I think the example is wrong (see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#983 for the issue
report about it).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- 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 what subobject it refers to, as the type of D::i is 'int B::*'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[Bug c++/41796] ambiguous subobject diagnostic given too early
--- 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);
};
struct I1: B1 { };
struct I2: B1 { };
struct D: I1, I2, B2 {
using B1::f;
using B2::f;
void g() {
f();// Ambiguous conversion of this
f(0); // Unambiguous (static)
f(0.0); // Unambiguous (only one B2)
int B1::* mpB1 = D::i; // Unambiguous - G++ gets this one wrong
int D::* mpD = D::i; // Ambiguous conversion
}
};
so, changing the subject line and removing the C++0x tag.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2010-02-09 22:28:30
date||
Summary|[C++0x] Extended sizeof |ambiguous subobject
|(referring to non-static|diagnostic given too early
|member) rises ambiguity |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
