🚀 go-pugleaf

just@TUDURZ.urz.tu-dresden.de (Gerald Just Physik ASB TUDR):
>z.Z. habe ich ein kleines Problem mit der Sichtbarkeit
>einer Variablen. Im Buch C++ Lernen von Tom Swan (Systhema Verlag)
>wird eine Klasse fuer Listen aus einer Klasse item abgeleitet:
>
>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.
>
>Der Zortech uebersetzt das problemlos.

Die Mehrheit hat in diesem Fall recht.
Eine als protected deklarierte Variable einer Basisklasse laesst sich nur
ueber einen Pointer (oder Referenz) auf die Subklasse ansprechen.
In diesem Fall wird in der Subklasse 'list' von 'item' versucht, ueber
einen Pointer auf eine 'item'-Instanz auf die Variable 'left' zuzugreifen,
was unzulaessig ist. Das ist zunaechst etwas verwirrend, laesst sich aber 
leicht motivieren:
Es waere ansonsten moeglich, dass sich unabhaengige Klassen gegenseitig als
protected deklarierte Variablen veraendern:

        class Base { protected: int i; };
        class Der1 : public Base {};
        class Der2 : public Base {
                public:
                void f(Base& b) { b.i=4711; }
        };

        Der1 d1;
        Der2 d2;
        d2.f(d1); 

In der letzten Zeile wuerde innerhalb der D2-Instanz, die in D1 als protected
deklarierte Variable 'i' veraendert, obwohl D1 und D2 zueinander in keinerlei
Beziehung stehen.
Das ganze ist ziemlich gut im ARM dargestellt (11.5 'Protected Member Access').

	Gruss
		Enno

>>>>> "Gerald" == Gerald Just Physik ASB TUDR <just@TUDURZ.urz.tu-dresden.de> writes:

Gerald> Hallo Leute,
Gerald> z.Z. habe ich ein kleines Problem mit der Sichtbarkeit
Gerald> einer Variablen. Im Buch C++ Lernen von Tom Swan (Systhema Verlag)
Gerald> wird eine Klasse fuer Listen aus einer Klasse item abgeleitet:

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

Gerald> class list:public item{
Gerald> 	private: item *anchor;
Gerald> 		 item *cip;

Das muss meines Erachtens so aussehen:

class list:public item{
	private: list *anchor;
		 list *cip;

Ich zitiere mal aus Bjarne Stroustrup (Die C++ Programmiersprache; 2.Auflage)

- Ist ein Element protected, so kann sein Name nur in
  Element-Funktionen und friends der Klasse verwendet werden, in der
  es definiert ist, oder in Elementfunktionen und friends einer von
  dieser Klasse abgeleiteten Klasse.


Eine Private Variable 'item *anchor' ist weder das eine noch das
andere. Deine Klasse list enthaelt aber jeweils ein Element *left und
*right. Deshalb kannst Du bei list *anchor auf left zugreifen.


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

Das ist auch richtig, s.o.

Gerald> Der Zortech uebersetzt das problemlos.

Zortech uebersetzt an dieser Stelle nicht richtig.

Gerald> Kann jemand von Euch einem Trottel begreiflichmachen, wann nun eine protected
Gerald> Sache sichtbar ist und wann nicht --- bitte bitte.

Gerald> 		Vielen Dank Gerald


Ich hoffe ich habe mich nicht allsu unverstaendlich ausgedrueckt.



	Gruss
		Frank
-- 
 Frank Nobis				Email: fn@Radio-do.de  PGP AVAILABLE
 Landgrafenstr. 130			       dg3dcn 
 44139 Dortmund	    Powered by FreeBSD  Fax: +49 231 7213816

Gerald Just Physik ASB TUDR (just@TUDURZ.urz.tu-dresden.de) wrote:
> Kann jemand von Euch einem Trottel begreiflichmachen, wann nun eine protected
> Sache sichtbar ist und wann nicht --- bitte bitte.

Das Problem hier besteht darin, dass anchor* vom Typ item ist. Objekte der
Klasse list dürfen natürlich auf ihre eigenen, ererbten Variablen left und
right zugreifen, genauso auf die anderer Objekte vom Typ list. Wie es
allerdings in dem Fall aussieht, wenn ein Nachfahr auf protected Variablen
eines anderen Objekts von Typ eines Vorfahren zugreift weiss ich selber
nicht. Ich schätze mal, daß die Fehlermeldung in dem Fall korrekt ist, weil
sich protected darauf bezieht, welche Zugriffe _bei_einer_Vererbung_ erlaubt
sind. Für einen direkten Zugriff auf ein anderes Objekt (wie hier) gilt wohl
die Regel, daß die Variablen public sein müssen.

Ich würde mal sagen, daß Du kein Trottel bist, sondern daß Du eine
interessante Frage aufgeworfen hast :-)

Gruß


        Uz


-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

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
------------------------------------------------

> Kann jemand von Euch einem Trottel begreiflichmachen, wann nun eine
> protected Sache sichtbar ist und wann nicht --- bitte bitte.
>
> 		Vielen Dank Gerald


Bei all den akademischen Ergüssen eine kleine praktische Richtlinie:

1) Deklariere alle Variablen als *protected*, damit sie abgeleiteten  
Klassen zur Verfügung stehen.

2) Deklariere alle Funktionen als *private*, von denen Du weißt, daß Du  
sie irgendwann brauchen wirst, aber keine Zeit hast sie augenblicklich zu  
implementieren (betrifft insbesondere den Bereich der Normalformen).

3) Deklariere alle Funktionen als *public*, die für Dich die intuitiv  
wesentliche Funktionalität bereitstellen.

Beachtest Du diese Regeln, kannst Du als Anfänger sicher sein, 99% aller  
Fälle richtig modelliert zu haben.


Gruss Arent

Arent

_____________________________________________________________________
Arent Gröbner                                      Darmstadt, Germany


## CrossPoint v3.02 ##

> >1) Deklariere alle Variablen als *protected*, damit sie abgeleiteten
> >Klassen zur Verfügung stehen.
>
> Oh, Boy!
>
> Da hast Du aber was mit der OOP nicht verstanden!

Ein bißchen weniger Überheblichkeit würde Dir nicht schaden...

> So umgehst Du ganz locker die Kapselung von Daten. Man brauch ja bei Deinen
> Klassen nur zu erben, um Attribute manipulieren zu können! Böse, böse...

Wenn man sich von einer Klasse ableitet, dann doch hoffentlich wegen einer  
wohlbegründeten Verwandschaftsbeziehung. Dann ist aber auch der Zugriff  
auf protected-Variablen wohlbegründet.

> Also... NIEMALS Variablen protected machen, außer in Ausnahmefällen ...

Das "NIEMALS" kannst Du getrost streichen. Mit dieser Art von Regeln  
versucht man bloß Erstsemester zu disziplinieren.

> Für den Zugriff sollten Memberfunktionen zur Verfügung gestellt werden,  
> die dann protected bzw. public sind.

Das ist bei Klassen richtig, die in keiner Vererbungsbeziehung stehen. Ein  
Zugriff über Memberfunktionen ist bei abgeleiteten Klassen wohl doch etwas  
übertrieben.

> _____________________________________________________________________
> Ralf Allar
> Allgemeine Informatik
> FH-Koeln Abt. Gummersbach


Arent

_____________________________________________________________________
Arent Gröbner                                      Darmstadt, Germany


## CrossPoint v3.02 ##

Hi,
Arent Groebner (arent@pegasus.RoBIN.de) wrote:
: > Ralf Allar wrote:
: > >1) Deklariere alle Variablen als *protected*, damit sie abgeleiteten
: > >Klassen zur Verfügung stehen.
: >
: > Oh, Boy!
: >
: > Da hast Du aber was mit der OOP nicht verstanden!

: Ein bißchen weniger Überheblichkeit würde Dir nicht schaden...

Nun, er hat nicht ganz unrecht: Die Regel "alle Variablen als
protected" zu deklarieren ist GANZ SCHLECHT! Auch wenn es eine
Verwandschaftsbeziehung zwischen den Klassen gibt, sollte man sie nur
so wenig wie moeglich koppeln. Zugriff auf einen Member ist IMMER, egal
ob von einer abgeleiteten Klasse oder von ausserhalb, eine starke
Kopplung.

: > So umgehst Du ganz locker die Kapselung von Daten. Man brauch ja bei Deinen
: > Klassen nur zu erben, um Attribute manipulieren zu können! Böse, böse...

: Wenn man sich von einer Klasse ableitet, dann doch hoffentlich wegen einer  
: wohlbegründeten Verwandschaftsbeziehung. Dann ist aber auch der Zugriff  
: auf protected-Variablen wohlbegründet.

Nein. Zugriff auf Variablen innerhalb einer Klasse, ist fast nie
wohlbegruendet.  Software aendert sich. Immer. Das heisst auch, dass
sich eine Klasse aendern kann und dass man sie anders repraesentiert.
Damit aendern sich typischerweise die Member-Variablen. Wenn man sie
protected hatte, so kann man sie, de facto, NICHT aendern: Irgendeine
abgeleitete Klasse koennte darauf zugreifen. Die Design-Entscheidung
eine Variable in den protected (oder gar public) bereich zu stellen
sollte also sehr gut ueberdacht sein! Zugriffsfunktionen sind fast
immer eine bessere Alternative.

: > Also... NIEMALS Variablen protected machen, außer in Ausnahmefällen ...

: Das "NIEMALS" kannst Du getrost streichen. Mit dieser Art von Regeln  
: versucht man bloß Erstsemester zu disziplinieren.

Auch mit dem "niemals" hat er recht (insbesondere, da explizit auf
Ausnahmefaelle hingewiesen wird): Es ist normalerweise eine
Design-Entscheidung die man bitter bereut.  Die Klasse und ihre
Repraesentation WIRD sich aendern. Welche Member-Variablen davon
betroffen sein werden laesste normalerweise nicht vorher absehen.

: > Für den Zugriff sollten Memberfunktionen zur Verfügung gestellt werden,  
: > die dann protected bzw. public sind.

: Das ist bei Klassen richtig, die in keiner Vererbungsbeziehung stehen. Ein  
: Zugriff über Memberfunktionen ist bei abgeleiteten Klassen wohl doch etwas  
: übertrieben.

Nein. Es ist nicht uebertrieben. In einem Projekt, mit mehreren hundert
Files und aehnlich vielen Klassen ist es eine Katastrophe, wenn man
eine Aenderung in vielen Files und vielen Klassen machen muss. Wenn man
eine Variable aendert, egal ob ihren Typ oder ihren Namen oder was
sonst noch, auf die von beliebig vielen Stellen zugegriffen wird, dann
hat man ein Problem. Objekt-Oriented Design ist unter anderem dazu
gedacht, um genau solche Probleme zu vermeiden: Eine Klasse hat eine
abgekapselte Darstellung, auf die durch wohldefinierte Methoden
zugegriffen wird. Waehrend man Methoden so aendern kann, dass sie ihr
altes Verhalten beibehalten, kann man das mit Variablen normalerweise
nicht machen. Man sollte immer bedenken, dass beliebig viele Klassen
auf einen protected Member zugreifen koennen: Es kann beliebig viele
abgeleitete Klassen geben (ausser man verhindert, dass von der Klasse
abgelitten werden kann oder beschraenkt die Menge der Klassen, die
davon ableiten koennen).

... und noch was zum Thema "uebertrieben": Ich abstrahiere teilweise
innerhalb von Klassen von Variablen! Wenn mir mehrere Darstellung einer
Abstraktion sinnvoll erscheinen, dann implementiere ich oft sogar die
Member der Klasse selbst mittels Zugriffsfunktionen. Uebertrieben?
Nein: Es hat mich oft genug davor bewahrt, viele verstreute Aenderungen
machen zu muessen anstatt einige wenige, nicht verstreute Aenderungen
zu machen. Vielleicht waere sogar ein Konzept wie "very private"
angebracht (allerdings laesst sich das leicht durch Basisklassen
modellieren, was ich auch oft mache).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic

... voellige Zustimmung.
	( Jedenfalls, wenn es um professionelle Arbeit geht. )

#pragma flame(on) 

Aber:	Vielleicht machen die's in Gummibach anders ?
	... und codieren Systeme > 100 000 loc nach ihrer eigenen,
	_geheimen_ Methode ?
( ich denke da an die beruehmte HTW -> HTR Methode. )
Let's think about it.

#pragma flame(off)

BTW: Bezueglich der Methoden, um Membervariablen zu aendern, gibt
es noch einen weiteren ( wenn auch nur spezifischeren ) Punkt:

Es kann passieren, dass abgeleitete Klassen diese Methoden
ueberschreiben, um a) die Wertaenderung zu loggen, oder b) um die
Wertaenderung _abzuweisen_ ! ( geht naturellemente nur bei virt. Methoden )

Auch sollte man im Hinblick auf eine moeglichen Codemigrationen zu
einer anderen Programmiersprache vorzeitig daran denken, dass 
beispielsweise Smalltalk nicht einmal zulaesst, auf Membervariablen
einer Instanz _desselben_ Klassentyps zuzugreifen ( ... man denke hier an 
Implementierungen von assignment-operator und copy-construktor ! )

__
Martin Prange (prange@cs.tu-berlin.de) ////////////////////////////////////////
Member of the ALMAP Team at Alcatel SEL Berlin //// Home: +49 30 7848958 //////
                                              //// Work: +49 30 7002 - 0 (OP) /