Fehler, Irrtümer, Fragen - Seite 1055

[borislg]

zfs:
Finden Sie servicedesk in Ihrem Profil.

Ich danke Ihnen!

[Koldun Zloy]

A100:
Hier liegt kein Widerspruch vor, denn sonst hätte B Zugang zu C.t, wie unten dargestellt, während B nicht von C abgeleitet ist

In Ihrem Beispiel sollte B Zugang zu C.t haben, und ich sehe keinen Grund, dies zu verbieten.

[Vladimir Gomonov]

Zloy_Koldun:
In Ihrem Beispiel sollte B Zugang zu C.t haben, und ich sehe keinen Grund, dies zu verbieten.

Ihr seid beide seltsam. Ihr verwechselt Klassen und Instanzen. Ich denke nicht, dass eine andere Instanz der gleichen Klasse B auch Zugang zu t haben sollte.

Geschützte Felder sollten nur von der eigenen (der gleichen B-Instanz, d.h. dieser) zugänglich sein, und andere Instanzen (sogar von der gleichen B-Klasse) sollten geschlossen sein... Lassen Sie es mich hier der Klarheit halber umbenennen:

class Человек
{
protected:
   int кошелёк;
};
class Мужчина : public Человек
{
   int fч( Человек& ч );
   int fм( Мужчина& м );
};
int Мужчина::fч( Человек& ч )  // 1
{
   кошелёк = 100;       // Всё в порядке.  моё.
   int s =  ч.кошелёк;   // protected member access error  вполне справедливо
   return s;
}
int Мужчина::fм( Мужчина& м )  // 2
{
   кошелёк = 100;       // Всё в порядке, кошелёк мой собственный
   int s = м.кошелёк;   // это компилируется.  и это НЕПРАВИЛЬНО! кошелёк ЧУЖОЙ !!
// С фига ли я должен иметь доступ к твоему кошельку, только на основании того что мы с тобой оба "Мужчины" ?? 
   return s;
}

D.h. für mich - beide Funktionen sollten nicht kompiliert werden, nicht nur die erste. Wenn in C++ die zweite kompiliert und funktioniert - dann ist es eine C++-Panne, keine Tugend.

Kurz gesagt:

class Человек
{
protected:
   int кошелёк;
public:
   void Человек() {  a=3; }
   void gч( Человек& ч )
   {
    ч.кошелёк--;  // Даже это не должно компилироваться.  не следует лазить в чужой кошелёк!
    кошелёк++;    // в свой можно
   }   
};

[Koldun Zloy]

Ihr Vergleich mit der Brieftasche ist falsch.

Ich kann Ihnen ein Beispiel nennen, bei dem Sie Zugang zu geschützten Mitgliedern benötigen, aber es geht nicht um meine oder Ihre Präferenzen.

Wenn der Programmierer etwas verbieten will, kann er es selbst tun und der Compiler muss es verbieten,

wenn es das Programm beeinträchtigen könnte.

Im obigen Beispiel weiß Klasse B über Klasse A Bescheid, so dass sie dort nichts durcheinander bringen wird.

Und wenn Sie es nicht zulassen wollen, stellen Sie es in den Abschnitt Private, oder erben Sie nicht von einer Klasse, oder denken Sie an tausend andere Möglichkeiten.

[A100]

MetaDriver:

D.h. für mich - beide Funktionen sollten nicht kompiliert werden, nicht nur die erste. Wenn in C++ die zweite kompiliert und funktioniert - ist das ein Fehler in C++, keine Tugend.

Dann wäre auch Ihr Portemonnaie nicht mehr zugänglich.

Человек ч;
ч.gч( ч );

[Vladimir Gomonov]

A100:
Dann würde auch nicht auf die Brieftasche zugegriffen werden

Noch einmal: Unterscheiden Sie sorgfältig zwischen Klassen (Typen) und Instanzen (Variablen). Eigene (diese) geschützte Felder sind frei zugänglich, auch durch Vererbung (im Gegensatz zu privat), andere (andere Variablen der gleichen Klasse) dürfen nicht zugänglich sein. (sollte unzugänglich sein)

Zloy_Koldun:
.....

Im obigen Beispiel weiß Klasse B über Klasse A Bescheid, so dass sie dort nichts durcheinander bringen wird.

...............

Nur weil ich weiß, dass Sie eine Brieftasche haben, ist das kein Grund, auf sie zuzugreifen. Auf Ihre bitte nur über get() und set() - wenn Sie es erlauben (public: int get(); int set();).

[A100]

MetaDriver:

protected schränkt den Zugriff nicht auf der Objektebene, sondern auf der Klassenebene ein, da zum Zeitpunkt der Kompilierung keine Objektinformationen vorliegen. Ich habe ein Beispiel für einen Widerspruch gegeben:

Человек ч;
ч.gч( ч );

object is the same

[Koldun Zloy]

MetaDriver:

Nur weil ich weiß , dass Sie eine Brieftasche haben, ist das kein Grund, darauf zuzugreifen. Auf Ihre - bitte. Auf Ihre - nur durch get() und set() - wenn Sie es erlauben (public: int get(); int set();).

Die Brieftasche ist nur ein Sonderfall. Und niemand hindert sie daran, in den privaten Bereich zu gelangen.

In einem anderen Fall müssen Sie vielleicht auf die Variable der Elternklasse eines anderen Objekts zugreifen.

Und es liegt im Ermessen des Programmierers, ob er dies zulässt oder nicht. Und der Compiler muss sicherstellen, dass das Programm korrekt funktioniert.

[Vladimir Gomonov]

A100:
Ich habe ein Beispiel für einen Widerspruch gegeben ... das Objekt ist dasselbe

Das ist kein Widerspruch. Wenn Sie sich durch eine "externe Schnittstelle" auf sich selbst beziehen, machen Sie sich darauf gefasst, von Ihnen selbst ins Gesicht geschlagen zu werden ;)

..........., da es zum Zeitpunkt der Kompilierung keine Informationen über die Objekte hat.

[Vladimir Gomonov]

Zloy_Koldun:

1. Die Brieftasche ist nur ein Sonderfall. Und niemand hindert sie daran, in den privaten Bereich zu gelangen.

2. In einem anderen Fall müssen Sie vielleicht auf die Variable der Elternklasse eines anderen Objekts zugreifen.

3 Und es ist Sache des Programmierers, zu entscheiden, ob er dies zulässt oder nicht.

4. und es ist Aufgabe des Compilers, dafür zu sorgen, dass das Programm korrekt funktioniert.

1. Das Einfügen in den privaten Bereich ändert nichts an der Tatsache, dass

class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // сейчас работает.  а не должно ;)
   }
};

Es wird sich vererben, das ist klar.

2. Es gibt nur sehr wenige Dinge, die getan werden müssen. Gründe sind nur verfügbar, wenn Sie auf Ihr eigenes Exemplar zugreifen.

3. Lassen Sie ihn entscheiden. richtig. ;)

4. Das ist die ganze Frage: Was genau gilt als "korrekte Arbeit"?