c++/3028: 3.0 Compiler complains about template that used to work under 2.95

peterson@austin.ibm.com peterson@austin.ibm.com
Fri Jun 1 07:26:00 GMT 2001


>Number:         3028
>Category:       c++
>Synopsis:       3.0 Compiler complains about template that used to work under 2.95
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 01 07:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     James Peterson
>Release:        version 3.1
>Organization:
>Environment:
Linux running on AMD
>Description:
The attached program is an isolated example of a problem that we
are running into.   This code compiles with the previous g++ Linux
compiler (version 2.95.2) but fails with the x86-64 g++ compiler
(version 3.1).

The previous compiler generated no errors; the new x86-64
compiler says:

/tmp/e.C: In member function `int IListBase<ALLOC>::find(int)':
/tmp/e.C:19: non-template type `IListNode' used as a template
/tmp/e.C:19: ISO C++ forbids declaration of `node' with no type

>How-To-Repeat:

template<class ALLOC> class IListBase 
{
 protected:
  struct IListNode 
  {
    IListNode *next;
    int datum;
  };
  
  class IListNode *head;
  class IListNode *tail;
  
  int find(int datum);
};

template<class ALLOC> int IListBase<ALLOC>::find(int d)
{
  IListNode<ALLOC> *node;
  for(node = head; node != 0; node = node->next)
    {
      if(node->datum == d)
	{
	  return 1;
	}
    }
  return 0;
}


>Fix:
A workaround seems to be to move the inner node class
out of the template list class and make it its own template
(but that breaks the protection).

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="e.C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="e.C"

CnRlbXBsYXRlPGNsYXNzIEFMTE9DPiBjbGFzcyBJTGlzdEJhc2UgCnsKIHByb3RlY3RlZDoKICBz
dHJ1Y3QgSUxpc3ROb2RlIAogIHsKICAgIElMaXN0Tm9kZSAqbmV4dDsKICAgIGludCBkYXR1bTsK
ICB9OwogIAogIGNsYXNzIElMaXN0Tm9kZSAqaGVhZDsKICBjbGFzcyBJTGlzdE5vZGUgKnRhaWw7
CiAgCiAgaW50IGZpbmQoaW50IGRhdHVtKTsKfTsKCnRlbXBsYXRlPGNsYXNzIEFMTE9DPiBpbnQg
SUxpc3RCYXNlPEFMTE9DPjo6ZmluZChpbnQgZCkKewogIElMaXN0Tm9kZTxBTExPQz4gKm5vZGU7
CiAgZm9yKG5vZGUgPSBoZWFkOyBub2RlICE9IDA7IG5vZGUgPSBub2RlLT5uZXh0KQogICAgewog
ICAgICBpZihub2RlLT5kYXR1bSA9PSBkKQoJewoJICByZXR1cm4gMTsKCX0KICAgIH0KICByZXR1
cm4gMDsKfQoKCg==



More information about the Gcc-bugs mailing list