francis@sunquest.UUCP (Francis Sullivan) (02/27/90)
The example below reproduces what I think is a minor bug in cfront 2.0 Does anyone know why the public namespace for the class constructor has the protected (or private) class constructors thrown in? ###### sun cfront 2.0 output ####### CC -sun4 -o prot prot.cc CC prot.cc: "prot.cc", line 36: error: two standard conversions possible for Goo::Goo(): struct Goo *Goo::(SomeStruct *) and struct Goo *Goo::(char *) "prot.cc", line 36: error: main() cannot access Goo::Goo(): protected member 2 errors ###### the input file: ####### #include <stream.h> class Goo { protected: struct SomeStruct { int i; }; SomeStruct *ss; char * name; Goo(SomeStruct *nss) { ss = nss; name = "fred"; } public: Goo(char *nname) { if (name == 0) name = "bertha"; else name = nname; ss = new SomeStruct; ss->i = 123; } Goo(const Goo& g) { name = g.name; ss = g.ss; } Goo duugh() { SomeStruct *nss = new SomeStruct; nss->i = 1; return Goo(nss); } void show() { cout << "ss->i is " << ss->i << ", name is " << name << "\n"; } }; main() { Goo a("harold"); Goo b(0); // line 36, I want to call the public Goo constructor!!! Goo c = b.duugh(); a.show(); b.show(); c.show(); } ############ end of input file ##### -- Francis Sullivan Sunquest Information Systems Tucson, AZ email: francis@sunquest.com or sunquest!francis@arizona.edu or {uunet,arizona}!sunquest!francis
rfg@ics.uci.edu (Ronald Guilmette) (02/27/90)
In article <2135@sunquest.UUCP> francis@sunquest.UUCP (Francis Sullivan) writes: >The example below reproduces what I think is a minor bug in cfront 2.0 > >Does anyone know why the public namespace for the class constructor has >the protected (or private) class constructors thrown in? > >###### sun cfront 2.0 output ####### >CC -sun4 -o prot prot.cc >CC prot.cc: >"prot.cc", line 36: error: two standard conversions possible for Goo::Goo(): struct Goo *Goo::(SomeStruct *) and struct Goo *Goo::(char *) >"prot.cc", line 36: error: main() cannot access Goo::Goo(): protected member >2 errors This is an interesting point about the language definition. When it is trying to decide which of several overloaded functions a particular call is actually refering to, a C++ implementation is first supposed to consider *all* of the *visible* possibilities (without regard to which of these possibilities are actually *accessable*). Once the implementation decides which of the overloaded possibilities should apply, then (and only then) does it (at the last minute) consider the issue of whether or not that (already determined) possibility is *accessable*. If the possibility selected as most correct for your call happens not to be *accessable* at the point of the call, you get an error. Hope that helps. // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.