shi_fuchs@dkauni5t.bitnet (Harald Fuchs) (06/15/89)
I'm trying to write a simple tree class, but I can't get it working
using G++ 1.35.0. It goes like that:
class link {
// Element of a doubly-linked list
friend class list;
friend class list_iterator;
link* p;
link* n;
protected:
link () { p = n = 0; }
public:
// ...
};
class list: link {
// Circular list: dummy header with forward and backward pointers
public:
list () { n = p = this; }
// ...
};
class list_iterator {
list* l;
link* x;
public:
list_iterator (list* a): l (a) { x = (link*) l; }
link* operator() () { if (x) { x = x->n; if (x == l) x = 0; } return x; }
void reset (list* a = 0) { if (a) l = a; x = (link*) l; }
};
class tree: list, link {
// A tree node has a list of sons (if not leaf)
// and is an element of such a list (if not root)
public:
// ...
};
A tree node must have TWO prev/next pointers to work. I think this is
the case because I didn't declare the ``link'' base class virtual. So
what's wrong here: G++ or my brain?
--
Harald Fuchs shi_fuchs@dkauni5t.bitnetsorensen@athena.mit.edu (Alma G. Sorensen) (07/23/89)
p 199 of Stroustrup tells how to specify arguments for the base class's constructor when deriving one class from another. What is the syntax for specifying arguments to more than one derived class (e.g. multiple inheritence in g++ 1.35.0)? I tried just listing the different arguments ala BS, and get errors like: image.h:252: initializer for unnamed base class ambiguous image.h:252: (type `int2D' uses multiple inheritance) image.h:252: initializer for unnamed base class ambiguous image.h:252: (type `int2D' uses multiple inheritance) Thanks in advance. Greg Sorensen sorensen@imager.mit.edu or sorensen@athena.mit.edu
roman@hri.com (Roman Budzianowski) (10/12/90)
I am having a hard time with multiple inheritance (cfront 2.0 on sparc).
Basically, when in the constructor of a derived class, parts of the
object are not initialized and as a result I get 'no mapping' errors
when I call methods of this object.
I can get it to work, but any minor change brings the problem again.
Here is the class hierarchy:
class Schema {
public:
virtual void f() {}
...a lot of virtuals
}
class WithSimpleSlot : virtual public Schema | class WithMethod :
virtual public Schema {}
{ |
void f() {} |
} |
...
class SystemSchema : public WithSimpleSlot, public WithMethod, public
WithNoRelation {}
class SchemaStream : public SystemSchema
{
...
SchemaStream() { f(); } // here is the problem
}
An instance of SchemaStream is created as a static object.
It appears that the cfront actually creates three copies of Schema, and
the methods called in the constructor of SchemaStream refer to a wrong copy.
Can somebody help me ? Is this a cfront bug, or a problem with the design.
Actually I got it to work, but it broke again when I tryed to make the
destructor for Schema virtual.
Below is an ouput from dbx, the 'no mapping' problem is due to
myNode.ptr being null, which is not.
(dbx) p *this
*`extstream`StreamSchema::StreamSchema`this = {
slotTable = 0x1aff20
[__vptr__14WithSimpleSlot = 0x1a278c]
PSchema = 0x1a22e0
OWithMethod = {
__vptr__10WithMethod = 0x1a25ac
PSchema = 0x1a22e0
OSchema = {
__W68__13SlotOwnerType = '\0'
schemaNameID = (nil)
myNode = {
ptr = (nil)
}
state = 0
lock = '\0'
__vptr__6Schema = (nil)
}
}
OWithNoRelation = {
__vptr__14WithNoRelation = 0x1a2500
PSchema = 0x1a22e0
OSchema = {
__W68__13SlotOwnerType = '\0'
schemaNameID = (nil)
myNode = {
ptr = (nil)
}
state = 0
lock = '\0'
__vptr__6Schema = (nil)
}
}
stream = 0x1a521c
OSchema = {
__W68__13SlotOwnerType = '\0'
schemaNameID = 0x1affb8
myNode = {
ptr = 0x1ad310
}
state = 0
lock = '\0'
__vptr__6Schema = 0x1a25e0
}
}
Thanks.thc@cs.brown.edu (Thomas Colthurst) (05/04/91)
I've got the following object inheritance hierarchy:
Object
/ \
/ \
Line Dependent
\ /
\ /
DependentLine
or in code,
class Object {
public:
Object();
~Object();
virtual void Draw() = 0;
virtual void Update() = 0;
virtual Object* Dup() = 0;
}
class Line: public virtual Object {
public:
Line();
~Line();
void Draw();
}
class Dependent: public virtual Object {
public:
Dependent();
~Dependent();
void Update();
}
class Dependent: public Line, public Dependent {
public:
DependentLine();
~DependentLine();
Object *Dup() { return( (new DependentLine) ); }; // error here
}
Sun CC version 2.1 gives me an error on the line
marked above, saying
"./ChildrenObjs.H", line 30: error: `new' of abstract class DependentLine
What am I doing wrong?
Thanks,
-Thomas Crobert@kohlrabi.tcs.com (Robert Blumen) (05/07/91)
In article <74462@brunix.UUCP>, thc@cs.brown.edu (Thomas Colthurst) writes: |> class Object { |> public: |> Object(); |> ~Object(); |> virtual void Draw() = 0; |> virtual void Update() = 0; |> virtual Object* Dup() = 0; |> } |> class Line: public virtual Object { |> public: |> Line(); |> ~Line(); |> void Draw(); |> } |> class Dependent: public virtual Object { |> public: |> Dependent(); |> ~Dependent(); |> void Update(); |> } |> class DependentLine : public Line, public Dependent { |> public: |> DependentLine(); |> ~DependentLine(); |> Object *Dup() { return( (new DependentLine) ); }; // error here |> } |> Sun CC version 2.1 gives me an error on the line |> marked above, saying |> "./ChildrenObjs.H", line 30: error: `new' of abstract class DependentLine For one thing, a class that inherits a pure virtual function must define it or redefine it to be pure virtual. ----------------------------------------------------------------------------- Robert Blumen | rblumen@tcs.com Senior Software Engineer | 2121 Allston Way, Berkeley, CA 94704 Teknekron Communications Systems, Inc. | (415) 649-3759
ilanc@microsoft.UUCP (Ilan CARON) (05/08/91)
C++ 2.1 now does for you the service of not requiring you to redeclare your pure virtual functions in derived classes (i.e. it automatically redeclares them for you as pure virtual). (2.0 made you redeclare them explicitly). |class Object { |public: | | Object(); | ~Object(); | | virtual void Draw() = 0; | | virtual void Update() = 0; | | virtual Object* Dup() = 0; | |} | |class Line: public virtual Object { |public: | | Line(); | ~Line(); | | void Draw(); // The 2.1 compiler effectively adds these decls. virtual void Update() = 0; virtual Object* Dup() = 0; | |} | |class Dependent: public virtual Object { |public: | | Dependent(); | ~Dependent(); | | void Update(); // The 2.1 compiler effectively adds these decls. virtual void Draw() = 0; virtual Object* Dup() = 0; | |} | | |class DependentLine: public Line, public Dependent { ^^^^ You forgot this |public: | | DependentLine(); | ~DependentLine(); | | Object *Dup() { return( (new DependentLine) ); }; // error here | |} | |Sun CC version 2.1 gives me an error on the line |marked above, saying | |"./ChildrenObjs.H", line 30: error: `new' of abstract class DependentLine | |What am I doing wrong? In order for a class to be concrete (non-abstract), so that you can create instances of it with operator 'new', it must be the case that it has no pure virtual functions. In above hierarchy, Object, Dependent and Line are clearly abstract classes. The question is: why is DependentLine also abstract? Well, DependentLine only explicitly overrides Dup(). What about Draw() and Update()? From one base class it inherits a pure virtual version and from the other an implementation. In any event, in the derived class it is not clear which version to "use". You might think that it should prefer the implementation as opposed to the pure virtual definition -- but on reflection that doesn't make much sense. Consider this fragment: Line *pLine = new DependentLine; pLine->Update(); // ??? use Dependent::Update() ??? So, in conclusion, DependentLine is an abstract class because it doesn't provide an explicit implementation for Draw() and Update(). Hope this makes sense. --ilan caron (uunet!microsoft!ilanc)
purtill@morley.rutgers.edu (Mark Purtill) (05/10/91)
robert@kohlrabi.tcs.com (Robert Blumen) writes: >For one thing, a class that inherits a pure virtual function must define it >or redefine it to be pure virtual. Not any more (see: E&S, sec 10.3, page 215, first commentary paragraph). Unless this has been changed again. ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (908)932-4580 (O) ((")) DIMACS, P.O. Box 1179, Rutgers U., Piscataway, NJ 08855 (908)220-6905 (H) ********** Note new area code! We are now (908) rather than (201)! **********
ilanc@microsoft.UUCP (Ilan CARON) (05/14/91)
In article <2153@godzilla.tcs.com> robert@kohlrabi.tcs.com (Robert Blumen) writes: >For one thing, a class that inherits a pure virtual function must define it >or redefine it to be pure virtual. > Actually this is no longer the case -- as of the ARM (p. 215), a pure virtual function is in fact inherited as a pure virtual. I.e. you don't need to redeclare it explicitly (if you're not defining it in the derived class). However, I believe this is only implemented in 2.1 conformant compilers. [This is a good design decision since otherwise "demoting" a pure virtual to an "impure" virtual in a base class would require mucking with all derived classes]. --ilan caron (uunet!microsoft!ilanc)
mgates@entiat.boeing.com (Michael Gates) (05/16/91)
>In article <2153@godzilla.tcs.com> robert@kohlrabi.tcs.com (Robert Blumen) writes: > In article <74462@brunix.UUCP>, thc@cs.brown.edu (Thomas Colthurst) writes: > |> class Object { > |> public: > |> Object(); > |> ~Object(); > |> virtual void Draw() = 0; > |> virtual void Update() = 0; > |> virtual Object* Dup() = 0; > |> } > |> class Line: public virtual Object { > |> public: > |> Line(); > |> ~Line(); > |> void Draw(); > |> } > |> class Dependent: public virtual Object { > |> public: > |> Dependent(); > |> ~Dependent(); > |> void Update(); > |> } > |> class DependentLine : public Line, public Dependent { > |> public: > |> DependentLine(); > |> ~DependentLine(); > |> Object *Dup() { return( (new DependentLine) ); }; // error here > |> } > |> Sun CC version 2.1 gives me an error on the line > |> marked above, saying > |> "./ChildrenObjs.H", line 30: error: `new' of abstract class DependentLine > > For one thing, a class that inherits a pure virtual function must define it > or redefine it to be pure virtual. G++ 1.39 compiles this with no trouble at all, which is correct. For each pure virtual function, there is a path from DependentLine to Object which defines that function. The ARM section 10.1.1 addresses this issue under the topic of name dominance. Page 205: A name B::f dominates a name A::f if its class B has A as a base. If a name dominates another no ambiguity exists between the two; the dominant name is used when there is a choice. (Followed by example) Here Line::Draw dominates the Object::Draw that is also inherited by DependentLine. Also Dependent::Update dominates Object::Update. -- et tu mgates?
ilanc@microsoft.UUCP (Ilan CARON) (05/22/91)
mgates@entiat.boeing.com (Michael Gates) considers the following
"diamond" hierarchy:
Object
Draw()=0;
Update()=0;
Dup()=0;
Line : virtual Object Dependent : virtual Object
Draw(); Update();
DependentLine : Line, Dependent
Dup() { new DependentLine; }
and says that:
> G++ 1.39 compiles this with no trouble at all, which is
>correct. For each pure virtual function, there is a path from
>DependentLine to Object which defines that function. The ARM section
>10.1.1 addresses this issue under the topic of name dominance.
>
> [ARM def of dominance omitted]
>
>Here Line::Draw dominates the Object::Draw that is also inherited
>by DependentLine. Also Dependent::Update dominates Object::Update.
While the above is true, it is irrelevant.
Dominance is an ambiguity resolution rule (IMHO of only marginal value),
that is used in resolving client code references to names. It says
nothing about how to *construct* an object -- in particular, it says
nothing wrt virtual function table contents.
As I pointed out in a previous posting (I believe):
> You might think that it should prefer the implementation as opposed to
> the pure virtual definition -- but on reflection that doesn't make
> much sense. Consider this fragment:
>
> Line *pLine = new DependentLine;
> pLine->Update(); // ??? use Dependent::Update() ???
^^^^^^^^^^^^^^^^
What does G++ do with this -- never-never-land? (I suppose Michael
might be thinking that this is a programmer bug).
>
> So, in conclusion, DependentLine is an abstract class because it
> doesn't provide an explicit implementation for Draw() and Update().
Note that the issue is not how to resolve references to names in the
scope of DependentLine, rather whether DependentLine is an abstract
class or not (since we're trying to construct an instance of it).
--ilan caron (uunet!microsoft!ilanc)mgates@entiat.boeing.com (Michael Gates) (05/25/91)
In article <72495@microsoft.UUCP> ilanc@microsoft.UUCP (Ilan CARON) writes: > mgates@entiat.boeing.com (Michael Gates) considers the following > "diamond" hierarchy: > > Object > Draw()=0; > Update()=0; > Dup()=0; > > Line : virtual Object Dependent : virtual Object > Draw(); Update(); > > DependentLine : Line, Dependent > Dup() { new DependentLine; } > and says that: > > > G++ 1.39 compiles this with no trouble at all, which is > >correct. For each pure virtual function, there is a path from > >DependentLine to Object which defines that function. The ARM section > >10.1.1 addresses this issue under the topic of name dominance. > > > > [ARM def of dominance omitted] > > > >Here Line::Draw dominates the Object::Draw that is also inherited > >by DependentLine. Also Dependent::Update dominates Object::Update. > > While the above is true, it is irrelevant. > > Dominance is an ambiguity resolution rule (IMHO of only marginal value), > that is used in resolving client code references to names. It says > nothing about how to *construct* an object -- in particular, it says > nothing wrt virtual function table contents. It is relevant to the extent that it is the only part of the ARM that *comes close* to addressing the problem. Since it is not explicitly laid to rest anywhere in the book, I certainly have no trouble changing my "which is correct" to "which is reasonable (IMHO)". The reasonableness and probable correctness is supported by section 10.10c, pages 233-235. I will explain after this quote. > As I pointed out in a previous posting (I believe): > > > You might think that it should prefer the implementation as opposed to > > the pure virtual definition -- but on reflection that doesn't make > > much sense. Consider this fragment: > > > > Line *pLine = new DependentLine; > > pLine->Update(); // ??? use Dependent::Update() ??? > ^^^^^^^^^^^^^^^^ > What does G++ do with this -- never-never-land? (I suppose Michael > might be thinking that this is a programmer bug). No, G++ *does* use Dependent::Update(). This is what it is supposed to do, per the second half of page 234: example (showing above behaviour) followed by "A call to a virtual function through one path in an inheritance structure may result in the invocation of a function redefined on another path. This is an elegant way for a base class to act as a means of communication between sibling classes, such as..." Clearly the dominance rule (or something similar) is being used to determine the contents of the final (DependentLine) vtable. In the example in the ARM, the final class (DependentLine here, BMW in the book) can get to the virtual base's "Update" (g() in the book) directly, can get to the virtual base's "Update" through "Line" (BW in the book), and can get to the redefined "Update" of "Dependent" (MW in the book). The latter is chosen to place in the final vtable. The reason I say "dominance rule (or something similar)" above is on page 235, 2nd paragraph: "To avoid ambiguous function definitions, all redefinitions of a virtual function from a virtual base must occur on a single path through the inheritence structure." Before anyone jumps up with > Note that the issue is not how to resolve references to names in the > scope of DependentLine, rather whether DependentLine is an abstract > class or not (since we're trying to construct an instance of it). let me point out that the ARM section in question is discussing how to build vtables. Unfortunately the case of pure virtual functions is not dealt with. In absence of direction, why should they be treated differently? -- et tu mgates?
Michael.Gates@sunbrk.FidoNet.Org (Michael Gates) (05/25/91)
In article <72495@microsoft.UUCP> ilanc@microsoft.UUCP (Ilan CARON) writes: > mgates@entiat.boeing.com (Michael Gates) considers the following > "diamond" hierarchy: > > Object > Draw()=0; > Update()=0; > Dup()=0; > > Line : virtual Object Dependent : virtual Object > Draw(); Update(); > > DependentLine : Line, Dependent > Dup() { new DependentLine; } > and says that: > > > G++ 1.39 compiles this with no trouble at all, which is > >correct. For each pure virtual function, there is a path from > >DependentLine to Object which defines that function. The ARM section > >10.1.1 addresses this issue under the topic of name dominance. > > > > [ARM def of dominance omitted] > > > >Here Line::Draw dominates the Object::Draw that is also inherited > >by DependentLine. Also Dependent::Update dominates Object::Update. > > While the above is true, it is irrelevant. > > Dominance is an ambiguity resolution rule (IMHO of only marginal value), > that is used in resolving client code references to names. It says > nothing about how to *construct* an object -- in particular, it says > nothing wrt virtual function table contents. It is relevant to the extent that it is the only part of the ARM that *comes close* to addressing the problem. Since it is not explicitly laid to rest anywhere in the book, I certainly have no trouble changing my "which is correct" to "which is reasonable (IMHO)". The reasonableness and probable correctness is supported by section 10.10c, pages 233-235. I will explain after this quote. > As I pointed out in a previous posting (I believe): > > > You might think that it should prefer the implementation as opposed to > > the pure virtual definition -- but on reflection that doesn't make > > much sense. Consider this fragment: > > > > Line *pLine = new DependentLine; > > pLine->Update(); // ??? use Dependent::Update() ??? > ^^^^^^^^^^^^^^^^ > What does G++ do with this -- never-never-land? (I suppose Michael > might be thinking that this is a programmer bug). No, G++ *does* use Dependent::Update(). This is what it is supposed to do, per the second half of page 234: example (showing above behaviour) followed by "A call to a virtual function through one path in an inheritance structure may result in the invocation of a function redefined on another path. This is an elegant way for a base class to act as a means of communication between sibling classes, such as..." Clearly the dominance rule (or something similar) is being used to determine the contents of the final (DependentLine) vtable. In the example in the ARM, the final class (DependentLine here, BMW in the book) can get to the virtual base's "Update" (g() in the book) directly, can get to the virtual base's "Update" through "Line" (BW in the book), and can get to the redefined "Update" of "Dependent" (MW in the book). The latter is chosen to place in the final vtable. The reason I say "dominance rule (or something similar)" above is on page 235, 2nd paragraph: "To avoid ambiguous function definitions, all redefinitions of a virtual function from a virtual base must occur on a single path through the inheritence structure." Before anyone jumps up with > Note that the issue is not how to resolve references to names in the > scope of DependentLine, rather whether DependentLine is an abstract > class or not (since we're trying to construct an instance of it). let me point out that the ARM section in question is discussing how to build vtables. Unfortunately the case of pure virtual functions is not dealt with. In absence of direction, why should they be treated differently? -- et tu mgates? * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
kulkarni@cs.umn.edu ( Srinivas R. Kulkarni (06/27/91)
piero@bnrmtl.bnr.ca (Piero Colagrosso) writes: > > I have been experiencing a problem with the use of multiple > inheritance in C++. I am using the Sun (AT&T) compiler on a Sun >... > The result: It seems that the calculation of the "this" pointer > which is passed to m1 (i.e.e C::m1 is done incorrectly, resulting in > defective code (an unexpected crash was the original symptom >...( scrumpy@.1991Jun19.104037.13020 ) We have observed a similar syndrome. Unfortunately, the resultant code isn't always kind enough to crash--in our case it quietly returns the wrong answer! What's curious is that it seems to handle the simple cases but fails on a slightly more complex one. Here is the (simplified) situation in which we have observed the problem. The classes are A, B, C and AA, BB, and CC. Methods m1, m2, and m3 with implementations on classes as indicated by '...'. All inheritance links are 'virtual', as are all method declarations. A...m1 /| / | m1...AA B...m2 | /| |/ | m2...BB C...m3 | / |/ m3...CC An instance *cc of CC is created and we invoke m1, m2, and m3 on it with the expected results as indicated by the trace and returned state information. The pointer cc is cast to a pointer *c of C, and the same methods are invoked. The correct _functions_ are entered in each case, but the "this" pointer is wrong in the case of m1, while it is correct in the cases of m2 and m3. Help! --------------------------------------------------------------------------- #include <stream.h> class A { public: virtual int m1( void ); }; class B : public virtual A { public: virtual int m2( void ); }; class C : public virtual B { public: virtual int m3(void ); }; A::m1( void ) { cout << "\ninvoking virtual A::m1 for object " << this << ": "; return 0; } B::m2( void ) { cout << "\ninvoking virtual B::m2 for object " << this << ": "; return 0; } C::m3( void ) { cout << "\ninvoking virtual C::m3 for object " << this << ": "; return 0; } class AA : public virtual A { public: int Avar; virtual int m1( void ); }; class BB : public virtual AA, public virtual B { public: int Bvar; virtual int m2( void ); }; class CC : public virtual BB, public virtual C { public: int Cvar; virtual int m3( void ); }; AA::m1(void) { cout << " Invoke AA.m1 on object " << this << ": "; return Avar; } BB::m2(void) { cout << " Invoke BB.m2 on object " << this << ": "; return Bvar; } CC::m3(void) { cout << " Invoke CC.m3 on object " << this << ": "; return Cvar; } main() { C *c; CC* cc = new CC; cc->Avar = 1; cc->Bvar = 2; cc->Cvar = 3; cout << "\n cc->m1(): " << cc->m1(); cout << "\n cc->m2(): " << cc->m2(); cout << "\n cc->m3(): " << cc->m3(); c = cc; // cast it cout << "\n\nCast CC to C\n"; cout << "\n c->m1(): " << c->m1(); cout << "\n c->m2(): " << c->m2(); cout << "\n c->m3(): " << c->m3() << "\n"; } --------------------------------------------------------------------------- Sample output: cc->m1(): Invoke AA.m1 on object 0x6614: 1 <<<-- desired result cc->m2(): Invoke BB.m2 on object 0x65f4: 2 cc->m3(): Invoke CC.m3 on object 0x65d8: 3 Cast CC to C c->m1(): Invoke AA.m1 on object 0x65f4: 2 <<<-- should be as above c->m2(): Invoke BB.m2 on object 0x65f4: 2 c->m3(): Invoke CC.m3 on object 0x65d8: 3 --------------------------------------------------------------------------- We are using a Sparc 1+ with the Sun (AT&T) Compiler 2.1 and SunOS 4.1.1. The code seems (from my understanding of the language) to be legal; certainly, the compiler does not issue even a peep of a warning message. Nonetheless, the results are disasterously wrong. Any explanations/workarounds/sympathy would be greatly appreciated. Please e-mail responses to: kulkarni@umn-cs.cs.umn.edu or harp@ssdc.honeywell.com