[comp.lang.c++] Gnu Gbugs?

randolph@ektools.UUCP (Gary L. Randolph) (05/16/89)

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.

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);
}

///////////////////Gnu OUTPUT///////////////////
The integer is: 25

The integers are: 2 and 3

The integer is: 3             //Here's the rub
 
AT&T followed the exact match rule without error.
 
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();
}
 
///////////////////Gnu OUTPUT///////////////////
x is: 4               //OUCH
 
AT&T correctly produces the error message x is private.
Note that Gnu works correctly *IF* the A:: is ommited. 
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.
 
PLEASE!!!! If any of the above has changed, let me know.
Part of the reason for this posting is to see if my
news is really successfully posted.
 
I hope that the posting of the exact match problem
saves someone the headache I received.  Headaches
should *NOT* be reusable!!!!
 
                Gary

diamond@diamond.csl.sony.junet (Norman Diamond) (05/17/89)

In article <1887@ektools.UUCP> randolph@ektools.UUCP (Gary L. Randolph) writes:

>Are the following current Gnu gbugs???

>1.)
>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(3.14); }

>The integer is: 3             //Here's the rub

>AT&T followed the exact match rule without error.

IMHO 3.14 is a constant of type double, which is not an exact match
for either float or int.  Looks like a bug in both gnu and cfront.

>2.)
>class A { private: int x; ... }
>class B : A { ... privPrint(){cout<<"x is: "<<A::x<<"\n";} ... }

Looks like a gbug to me.

>3.)
Wants
>Federation::Federation(char* util, char* id, int meds,
>                        int fp, int sob)
>                        :StarCruiser(util)
instead of
>Federation::Federation(char* util, char* id, int meds,
>                        int fp, int sob)
>                        :(util)

One of Dr. Stroustrup's published articles has already promised this.
In fact, it will be necessary to do this with multiple inheritance.

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-implementing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?