🚀 go-pugleaf

just@TUDURZ.urz.tu-dresden.de (Gerald Just Physik ASB TUDR) wrote:

>class item{
>	protected:
>		item *left;
>		item *right;
>	public:
>		item();
>		item *link(item *);
>		void unlink();
>	};

>class list:public item{
>	private: item *anchor;
>		 item *cip;
>	public: .
>		.
>		.
>                int atEnd(void){return((anchor!=NULL)&&(cip==anchor->left));}
>		.
>		.
>			};
>Fuer diese Sache bringen DJGPP, MS und Borland die Meldung, dass anchor->left
>protected ist und nicht zur Verfuegung steht.

Dies ist korrekt. 
Ein Objekt einer Ableitung enthält automatisch alle Datenmitglieder
der Basisklassen. Ein Objekt der Klasse "list" enthält also u.a. die
Zeiger "left" unf "right". 
Die "protected"-Deklaration dieser Mitglieder besagt nun, daß eine
(öffentliche) Ableitung darauf zugreifen darf. Hier kann also "list"
(genauer: Mitgliedsfunktionen von "list" können) auf "left" und
"right" zugreifen. 
In der Anweisung 

>                int atEnd(void){return((anchor!=NULL)&&(cip==anchor->left));}

wird eine Mitgliedsfunktion deklariert und definiert. Sie greift
jedoch nicht auf "left" des eigenen Objekts zu, sondern auf "left"
eines ganz anderen Objekts, nämlich auf das, auf das "anchor" zeigt. 

Es handelt sich daher bei dem Ausdruck

>	anchor->left

um einen Zugriff auf ein Objekt von aussen. Damit dies möglich ist,
muß "left" wie gewohnt "public" sein. "Protected" bezieht sich immer
ausschließlich auf die Mitglieder des eigenen Objekts. 

Folgende Lösungsmöglichkeiten bestehen:

1. "left" wird "public" deklariert. Damit läuft das Beispiel, aber nun
ist left von überall aus zugreifbar (schlecht!)

2. "list" wird als Freund zu "item" deklariert. Damit läuft das
Beispiel auch, aber nun muß "item" für jede Ableitung verändert werden
(nämlich um immer neue  Freund-Deklarationen aufzunehmem) (NOCH
SCHLECHTER!) Warum? Alle Ableitungen aller Projekte, die "item" als
Basisklasse verwenden, müssen rekompiliert werden, da sich die
Deklaration von "item" verändert hat - und das obwohl  "item" an sich
unverändert bleibt. 

3. Das Design (und das Buch) vergessen und auf eine Listklasse
zurückgreifen, die diese Probleme nicht hat. 

>Der Zortech uebersetzt das problemlos.

Wirklich? Gibt er auch keine Warnung aus?

>Kann jemand von Euch einem Trottel begreiflichmachen...
                                                        ~~~~~~~~
Kopf hoch! Jeder stolpert früher oder später über solche Feinheiten
der Sprache. Das Problen ist eher, daß viele Buchautoren die Sprache
nicht gut kennen und Probleme umgehen oder ignorieren anstatt ihnen
auf den Grund zu gehen. BTW, vielleicht schaust Du mal in mein Buch
rein... (Programmierhandbuch Visual C++, ISBN 3-528-05305-4,
Vieweg-Verlag). Dort sind dieses und andere Probleme detailliert
beschriebem

>		Vielen Dank Gerald
		Gern geschehen - Martin


------------------------------------------------
Martin Aupperle
100754.2730@compuserve.com
OOA,OOD,OOP with C++, courses,trainig,coaching,books
resources available. email for info
------------------------------------------------