--- Additional Comments From bangerth at dealii dot org 2005-03-14 16:25
---
The place to look at is 12.6.2/2:
2 Names in a mem-initializer-id are looked up in the scope of the
constructor's class and, if not found in that scope, are looked up in
the scope containing
--- Additional Comments From giovannibajo at libero dot it 2005-03-05
11:32 ---
In fact, "bar" and "foo" should be injected into class scope. Comeau, however,
flag the code as invalid just like GCC does. I do not have a standard handy
now to double-check.
--
http://gcc.gnu.org/bug
--- Additional Comments From igodard at pacbell dot net 2005-03-05 09:37
---
Ref comment #4: yes, using "::" clears the diagnostic, but why does the member
in one base collide with the direct reference to another explict base? Isn't the
base name itself in the derived's scope, supercedin
--- Additional Comments From pcarlini at suse dot de 2005-03-05 09:11
---
::bar() ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20330
--- Additional Comments From igodard at pacbell dot net 2005-03-05 08:18
---
Reduced test case:
struct foo { int bar; };
template
struct bar {};
template
struct baz : public foo, public bar {
baz() : foo(), bar() {}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
What|Removed |Added
Attachment #8333|application/octet-stream|text/plain
mime type||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20330
--- Additional Comments From igodard at pacbell dot net 2005-03-05 08:02
---
Created an attachment (id=8334)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8334&action=view)
Source code (-save-temps) (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20330
--- Additional Comments From igodard at pacbell dot net 2005-03-05 08:01
---
Created an attachment (id=8333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8333&action=view)
Compiler output (-v -save-temps)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20330
