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?