Path: utzoo!telly!attcan!uunet!tut.cis.ohio-state.edu!YAHI.STANFORD.EDU!tiemann
From: tiemann@YAHI.STANFORD.EDU (Michael Tiemann)
Newsgroups: gnu.g++
Subject: Gnu Gbugs?
Message-ID: <8905161613.AA01825@yahi.stanford.edu>
Date: 16 May 89 16:13:10 GMT
References: <1887@ektools.UUCP>
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: tiemann@lurch.stanford.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 114


   Path: mit-eddie!rutgers!rochester!kodak!ektools!randolph
   From: ektools!randolph@ai.mit.edu (Gary L. Randolph)
   Newsgroups: comp.lang.c++
   Date: 16 May 89 14:22:54 GMT
   Sender: randolph@ektools.mit.edu (Gary L. Randolph)
   Organization: Eastman Kodak, Dept. 47, Rochester N.Y.
   Lines: 105
   Apparently-To: lang-c++-netnews-dist@wheaties.ai.mit.edu

   I have been using both AT&T's cfront and Gnu's g++ compiler.
   My copy of Gnu's g++ is about 3 months old so some of
   what follows may be dated.
It is.

   Are the following current Gnu gbugs???

   1.)
      The exact match rule that Stroustrup (pgs. 122 and 290)
      discusses does not work.  The following was used as a
      test:

   overload show;

   void show(int x)
   {
   cout<<"\nThe integer is: "<<x<<"\n";
   }
   void show(int x, int y)
   {
   cout<<"\nThe integers are: "<<x<<" and "<<y<<"\n";
   }

   void show(float f)
   {
   cout<<"\nThe float is: "<<f<<"\n";
   }

   main()
   {
   show(25);
   show(2,3);
   show(3.14);
   }

When compiled with GNU C++ 1.35.0, the program prints this:

yahi% a.out

The integer is: 25

The integers are: 2 and 3

The float is: 3.14
yahi% 

   2.)
     If I use the class name and the scope resolution
     operator, I can access private base parts from a
     derived class!!!  Here is an example:

   class A
   {
   private:
     int x;
   public:
     A(int y){x = y;}
   }; 
   class B : A
   {
   public:
     B(int y):(y){}
     privPrint(){cout<<"x is: "<<A::x<<"\n";}
   };

   main()
   {
   B b(4);
   b.privPrint();
   }

   AT&T correctly produces the error message x is private.
   Note that Gnu works correctly *IF* the A:: is ommited. 

This is no longer a bug:

GNU C++ version 1.35.0 (sparc) compiled by GNU C version 1.35.
In method int B::privPrint ():
x.c:14: member `x' is a private member of class `A'

   3.)
     I also have a small complaint about cfront that may
     be changed in 2.0.  When I look at the constructor
     for a derived class, I like to have the base class
     name explicit. For instance, say I have a class named
     StarCruiser that is constructed with a char*.  I
     like to see this name in the constructor for the
     derived class, Federation.

   Federation::Federation(char* util, char* id, int meds,
			   int fp, int sob)
			   :StarCruiser(util)
   NOT the following:

   Federation::Federation(char* util, char* id, int meds,
			   int fp, int sob)
			   :(util)

   I know the base class name is optional on many c++
   implementations and would like cfront to stop
   choking on this.
GNU C++ has supported this feature since December, 1987.

Michael