Anmerkungen eines Anfängers zu C++

thordk

Walter_vdV schrieb:

GPC, ich wollte damit ausdrücken, dass im normalen Sprachgebrauch (auch im Englischen) protected in der Sicherheitshirarchie höher einzuordnen ist als private.

eigentlich nicht. ein bereich muss "protected" sein, wenn er anderen zugang gewährt, damit man ihnen auf die finger guckt, dass sie keinen unfug treiben.

zu "private" bereichen hat niemand zugang, da ist die tür einfach abgeschlossen. weshalb man auch kein wachpersonal ("protected") braucht.

Marc++us

Blue-Tiger schrieb:

Deine Anmerkungen sind reiserisch, und du hast keine Einzige davon begruendet.

a) ich hab's verstanden und fand es lustig
b) man kann jeden Witz und jede Ironie auch zu Tode reden

groovemaster

Walter_vdV schrieb:

3. Ist C++ nicht im Ganzen Überladen, wie die überladenen Funktionen.

Ob C++ überladen ist? Mag durchaus sein. C++ hat aber auch nie den Anspruch erhoben, domänenspezifisch zu sein. Und was du hier als Gimmick bezeichnest, hat sich in der Praxis durchaus als hilfreich erwiesen. Wie sagt ein bekannter Einrichtungsausstatter doch, "entdecke die Möglichkeiten".

Walter_vdV schrieb:

6. public, privat, protected im übertragenen Sinne: Mein Vorgarten, sofern er nicht eingezäunt ist, ist mehr oder weniger public. Privat ist mein Wohnbereich in dem Gäste willkommen sind. Protected ist mein Tresor, zu dem nur ich einen Zugang habe. In C++ haben Leute zu meinem Tresor Zugang obwohl sie gar nicht meine Gäste sind.

Nein, deine Logik passt nicht. Dein Denkfehler besteht darin, dass du deine Gäste als private siehst, nur weil sie sich in deinem Wohnbereich aufhalten. Das sind sie aber nicht. Die sind nur zu Besuch, also Aussenstehende. Wären sie private, würden sie dort wohnen und hätten damit die gleichen Rechte wie du, also auch Zugang zum Tresor.
Protected mag für dich vom Namen her vllt. etwas irreführend sein, denn private ist genauso "geschützt" wie protected. Nur dass private bedingungslos geschützt ist, protected nicht.

Jester

groovemaster schrieb:

Nein, deine Logik passt nicht. Dein Denkfehler besteht darin, dass du deine Gäste als private siehst, nur weil sie sich in deinem Wohnbereich aufhalten. Das sind sie aber nicht. Die sind nur zu Besuch, also Aussenstehende. Wären sie private, würden sie dort wohnen und hätten damit die gleichen Rechte wie du, also auch Zugang zum Tresor.
Protected mag für dich vom Namen her vllt. etwas irreführend sein, denn private ist genauso "geschützt" wie protected. Nur dass private bedingungslos geschützt ist, protected nicht.

Jo, so is das in C++. Sprachlich nutzt man das aber trotzdem anders.

DEvent

Walter_vdV schrieb:

6. public, privat, protected im übertragenen Sinne: Mein Vorgarten, sofern er nicht eingezäunt ist, ist mehr oder weniger public. Privat ist mein Wohnbereich in dem Gäste willkommen sind. Protected ist mein Tresor, zu dem nur ich einen Zugang habe. In C++ haben Leute zu meinem Tresor Zugang obwohl sie gar nicht meine Gäste sind. Diese Unlogik .........., Unlogik ???, na ja habe mich in letzter Zeit doch ein bisschen zu viel mit C++ beschäftigt.

Ich hab den Text so verstanden, das man seinen Freunden den Bereich zu privaten Gegenden erlaubt

class Foo 
{
    private:
        int x;
        friend void blaa(Foo& foo);
}

// blaa ist der Freund von Foo und somit kann es in den privaten Bereich
void blaa(Foo& foo)
{
    foo.x = 50;
}

Protected wäre dann die private Wohung, in die auch meine Kinder reinkönnen. Einen Tresor, bei dem nur ich Rechte hätte, gibt es in C++ nicht.

Walter_vdV schrieb:

7. Mangels adäquater Alternativen werde ich, ähnlich wie bei bei Windows, trotzdem bei C++ bleiben. Es ist immer noch besser nur von zehntausend anstatt von zwanzigtausend Bienen attackiert zu werden bevor man den begehrten Honig erhält.

Wie schon jemand gesagt hat, genau wie es zu Windows adäquater Alternativen gibt, gibt es auch zu C++ diese.

Ich fand des Text trotzdem witzig

krabbels

Einen Tresor, bei dem nur ich Rechte hätte, gibt es in C++ nicht.

natürlich hast du den mit private.
friend kommt eher einem einbruch gleich :p

CStoll

krabbels schrieb:

Einen Tresor, bei dem nur ich Rechte hätte, gibt es in C++ nicht.

natürlich hast du den mit private.
friend kommt eher einem einbruch gleich :p

Nein, mit "friend" gibst du jemandem die Tresor-Schlüssel. Einbruch wäre es, wenn jemand ohne deine Zustimmung an den Tresor-Inhalt kommt.

Und natürlich kannst du in C++ auch einen Tresor anlegen:

class Haus
{
private:
  class Tresor
  {
  private:
    int secret_data;
    friend class house;
  };
  tresor mein_tresor;

  friend class Freund;
};

Die Klasse "Freund" darf zwar in mein Haus (protected-Bereich) und Wohnzimmer (private-Bereich), kommt aber nicht an den Tresor-Inhalt.

Cpp_Junky

Mal im Ernst, arbeitet jemand von euch so richtig konsequent ersthaft mit public/private/protected ?

Artchi

Cpp_Junky schrieb:

Mal im Ernst, arbeitet jemand von euch so richtig konsequent ersthaft mit public/private/protected ?

Ja.

DEvent

Cpp_Junky schrieb:

Mal im Ernst, arbeitet jemand von euch so richtig konsequent ersthaft mit public/private/protected ?

ja, natürlich

GPC

Cpp_Junky schrieb:

Mal im Ernst, arbeitet jemand von euch so richtig konsequent ersthaft mit public/private/protected ?

Ja, wieso auch nicht?

CStoll

protected verwende ich eher selten, aber sonst achte ich schon auf eine klare Trennung.

Dravere

Cpp_Junky schrieb:

Mal im Ernst, arbeitet jemand von euch so richtig konsequent ersthaft mit public/private/protected ?

Ich will es jetzt einfach mal vorsetzen:
Klaro, was meinst du denn?

@CStoll
Also für Vereerbungen ist protected ja das Paradies. Sobald ich starke Vereerbungstrukturen habe, dann findest du bei mir kaum noch eine private-Variable sondern nur noch protected.

Und an den Threadstarter:
Lustiger Kerl du
Dir könnte man nicht einmal Java empfehlen, welches ja "einfacher" als C++ sein soll. Dir kann man nur empfehlen das Programmieren lieber sein zu lassen, denn diese "Probleme" gehören unteranderem zum Alltag eines Programmieres (mehr oder weniger ^^)
Des weiteren lernt man irgendwann, wie man die Probleme so anpackt, dass man nicht mal mehr ins Haus rein muss, sondern das Haus so bauen lässt, dass das Haus sich darum kümmert, dass du rein kommst ... *lol* ^^

Grüssli

DEvent

Also für Vereerbungen ist protected ja das Paradies. Sobald ich starke Vereerbungstrukturen habe, dann findest du bei mir kaum noch eine private-Variable sondern nur noch protected.

Du gibst deinen Kind-Klassen vollen Zugriff auf die Attribute der Eltern-Klasse? ohje...

Artchi

Protected benutze ich nur für Methoden. Attribute dagegen IMMER private.

Dravere

DEvent schrieb:

Du gibst deinen Kind-Klassen vollen Zugriff auf die Attribute der Eltern-Klasse? ohje...

Das habe ich nicht gesagt! Aber über protected kann man gewissen Zugriff weitergeben und das kann durchaus sehr oft sinnvoll sein. Übergibst du denn Kindklassen nie irgendwelchen Zugriff auf Attribute oder Methoden der Mutterklasse? Ohje...

Grüssli

Jester

Dravere schrieb:

DEvent schrieb:

Du gibst deinen Kind-Klassen vollen Zugriff auf die Attribute der Eltern-Klasse? ohje...

Das habe ich nicht gesagt! Aber über protected kann man gewissen Zugriff weitergeben und das kann durchaus sehr oft sinnvoll sein. Übergibst du denn Kindklassen nie irgendwelchen Zugriff auf Attribute oder Methoden der Mutterklasse? Ohje...

Lies mal http://www.gotw.ca/gotw/070.htm und sag dann nochmal Ohje.
Das sagt, warum Attribute niemals protected sein sollten. Bei Funktionen natürlich gerne. Der Grund in Kürze: Angenommen Du schreibst ne Klasse und ich erbe davon. Erlaubst Du mir direkten zugriff auf Deine Attribute, dann garantiert Dir niemand, dass ich Deine Invarianten respektiere. Erlaubst Du den zugriff nur über protected-Funktionen, dann kann die Details von draußen immer noch keiner sehen und zusätzlich hast Du die Kontrolle darüber was Klassen die von deiner erben mit Deinen Variablen anstellen. Interessant wird das ganze natürlich erst wenn man in der Situation ist, dass derjenige der ne Klasse schreibt und derjenige der davon erbt nicht mehr die selbe Person sind.

Dravere

Tja, bisher war immer ich die alleinige Person, welche Zugriff auf die Klasse hatte. Sobald natürlich jemand anderes darauf zugreifen können soll, ist mir klar, dass dies nicht mehr so sinnvoll wird bei Attributen. Ausser, wenn man z.b. sowas hat:

class CHull
{
    // ...
protected:
    int m_nHitPoints;

public:
    int getHitPoints() const { return m_nHitPoints; };
    // ...
}

class CWarShip : public CHull
{
    // ...
}

class CTradeShip : public CHull
{
    // ...
}

Wieso sollte man da nicht das Attribut, gleich als solches übergeben. In CHull kann man mit den Hitpoints womöglich nichts anfangen, es dient nur als gemeinsames Attribut, welche eben alle Kind-Klassen gemeinsam haben.
Es kommt halt ein wenig drauf an, wie man das ganze aufbaut. Aber es gibt sicherlich Momente, wo es durchaus angebracht ist, protected Attribute hinzusetzen.
Ok, aber eigentlich habe ich in meinem ersten Post wirklich nen Fehler gemacht, ich habe unter Variablen irgendwie auch die Methoden gesehen ^^
Wenn ihr erlaubt, so ändere ich das im oberen Post ^^

Grüssli

Jester

Was ist, wenn bei Änderungen an Hitpoints gewisse Ereignisse ausgelöst werden müssen? Die könnten dann in der Kindklasse weggelassen werden. Das einfach verstecken der Variable im private-Bereich nebst protected setter oder besser doDamage(unsigned int) und repair(unsigned int), löst dieses und alle ähnlichen Probleme mit einem Schlag auf elegante Art und Weise.

Ich würde mal so sagen: Momente wo es angebracht ist protected-Attribute zu verwenden gibt es nicht. Aber es gibt Momente wo es zumindest nicht schädlich ist.

DEvent

In CHull kann man mit den Hitpoints womöglich nichts anfangen

Wie "nichts anfangen", wozu hat dann Hull dieses Attribut? Eine Schiffshülle kann man reparieren. Ein CHull::repair() und schon kann Warship und Tradeship ihre Hülle reparieren.