[Bug c++/20330] New: Constructor fails to find base class in specialization

[Bug c++/20330] New: Constructor fails to find base class in specialization

[igodard at pacbell dot net]

The compiler complains about only one of two specializations that are broadly 
identical. I don't see any error in either.

If this example should turn out to actually be invalid, please change this report 
to a complaint about the quality of the diagnostic.

Ivan

-- 
           Summary: Constructor fails to find base class in specialization
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20330] Constructor fails to find base class in specialization

[igodard at pacbell dot net]

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

[Bug c++/20330] Constructor fails to find base class in specialization

[igodard at pacbell dot net]

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

[Bug c++/20330] Constructor fails to find base class in specialization

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8333|application/octet-stream    |text/plain
          mime type|                            |


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

[Bug c++/20330] Constructor fails to find base class in specialization

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-05 08:18 -------
Reduced test case:

struct foo { int bar; };
template<int i>
struct bar {};
template<int i>
struct baz : public foo, public bar<i> {
        baz() : foo(), bar<i>() {}
        };



-- 


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

[Bug c++/20330] Constructor fails to find base class in specialization

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-03-05 09:11 -------
::bar<i>() ?

-- 


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

[Bug c++/20330] Constructor fails to find base class in specialization

[igodard at pacbell dot net]

------- 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, superceding the names in the base
scopes? That is, from baz are foo and its member bar in the same scope (which is
apparently what the compiler thinks), or is foo in baz's scope while the member
bar is in baz::foo's as seems more reasonable?

(Yes, I know, reasonableness is non-standard :-)

Ivan

-- 


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

[Bug c++/20330] Constructor fails to find base class in specialization

[giovannibajo at libero dot it]

------- 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/bugzilla/show_bug.cgi?id=20330

[Bug c++/20330] Constructor fails to find base class in specialization

[bangerth at dealii dot org]

------- 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  the  constructor's  definition.  [Note: if the 
  constructor's class contains a member with the same name as  a  direct 
  or  virtual  base  class of the class, a mem-initializer-id naming the 
 
  member or base class and composed of a single identifier refers to the 
  class  member.   A mem-initializer-id for the hidden base class may be 
  specified using a qualified name.   ]  Unless  the  mem-initializer-id 
  names  a  nonstatic data member of the constructor's class or a direct 
  or virtual base of that class, the mem-initializer is  ill-formed.   A 
  mem-initializer-list  can  initialize a base class using any name that 
  denotes that base class type.  
 
Obviously, in the scope of the constructor, both the name of the base 
class and the name of the member of foo are visible. The standard specifies 
that this then denotes the member variable, and the sentence after that 
states that this is then an error because the variable is not one of the 
present class. 
 
In other words, gcc's behavior is correct even though there would be an 
unambiguous resolution in this very particular case. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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