Anmerkungen eines Anfängers zu C++

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.

krabbels

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

ich finde dieses "friend" konstrukt recht seltsam und bin der meinung, dass man die datenkapselung sowiso nicht einfach unterlaufen können sollte. deshalb die analogie zum einbruch.
natürlich hast du recht.

Dravere

DEvent schrieb:

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.

Nein kann man in dem Fall nicht. Und ein Tradeship kann keine Hippoints verlieren und kann auch nicht sich reparieren, aber besitzt welche und zwar eigentlich für nix ^^
Wieso das so ist? Fragt mich nicht, ist in einem Spiel so und ich habe eine Verwaltung dazu erstellt und es mussten halt alle Daten verwaltet werden. CHull hatte somit nur eine einzige Methode, welche die Hitpoints betraf und das war dieses getHippoints(). Ein Tradeship musste aber trotzdem einen Speicherbereich für Hitpoints haben, wie ein WarShip. So habe ich das eben in die Hülle gepackt und als protected deklariert. Ich wüsste nicht, wie das Schaden könnte. Und ich fände es idiotisch, wenn ich nun im WarShip und im TradeShip ein Attribut für die Hitpoints deklarieren müsste
Auch könnte ich dann nicht mehr ein Hüllenpointerarray durchlaufen und alle Hitpoints ausgeben
Die Lösung passt in dem Fall für mich perfekt und deshalb bin ich auch der Meinung, dass es Situationen gibt, wo ein protected Attribut auch angebracht ist.

Die angesprochenen repairs und weiss zum Kuckkuck nicht alles kenne ich auch und dort verwende ich dann auch privat, weil es einfach völlig Fehleranfällig wäre mit protected. Aber wie gesagt, habe mich ja ein wenig versprochen, war in einer Mathevorlesung und da ist mir wohl irgendwie der Name Variable nachgelaufen
Sobald man allerdings Attribute + Methoden dort oben hinschreibt, dann ist es natürlich die Mehrzahl, wegen den Methoden, weil es ja meistens von denen mehr hat als Attribute.

Grüssli

CStoll

krabbels schrieb:

ich finde dieses "friend" konstrukt recht seltsam und bin der meinung, dass man die datenkapselung sowiso nicht einfach unterlaufen können sollte. deshalb die analogie zum einbruch.
natürlich hast du recht.

Was ist denn daran seltsam? Einen friend sehe ich normalerweise als eine externe Hilfsklasse, die mich bei meiner Arbeit unterstützen soll - und dazu benötigt sie auch etwas mehr Informationen als der Rest der Welt (z.B. benötigt ein Container-Iterator das Wissen, wie der Container aufgebaut ist, also benötigt er Zugriff auf dessen interne Strukturen, für den Rest der Welt reicht es zu wissen, daß der Container die Daten irgendwie speichert und daß der Iterator weiß, wie er rankommt)

@Dravere: Wenn nur Kriegsschiffe Hitpoints haben sollen (was ist denn das für ein Spiel?), dann benötigen Handelsschiffe auch kein entsprechendes Attribut - sprich: Der Member m_nHitPoints und die entsprechende Zugriffsmethode gehören nicht in die Basisklasse.
(wenn es unbedingt sein soll, würde ich die getHitPoints() virtuell anlegen (entweder pur virtuell oder als Dummy-Funktion "return -1;"))

DEvent

Ein friend-Funktion oder Klasse ist ok, weil man explizit angeben muss, welche Klasse/Funktion friend ist. Allerdings finde ich es besser, die friend-Klasse als inner-class zu machen, weil eine friend-Klasse nicht ohne die richtige Klasse funktionieren kann.

Walter_vdV

Auf Grund verschiedener Anmerkungen, möchte ich noch mal betonen, dass mein Beitrag rein ironisch gedacht war und Gott sei Dank haben es die meisten auch so verstanden. Bezüglich der Alternativen sollte man den Text auch mal genau lesen.
Das mit dem private, protected und public ist mir nur eingefallen, weil ich es eben so ausgelegt habe, wie ich es umgangssprachlich deute und in meiner ersten Klasse die internen Variablen als protected deklariert habe (grgrgrgr). Vielleicht fällt mir ja wieder was ironisches ein, bei dem sich manche dann nicht so auf den Schlips getreten fühlen. So long und viel Spass beim programmieren.
Gruss Walter

Erhard Henkes

Ist doch schön, wenn jemand C++ "witzig" findet. das erhöht den Spaßfaktor beim Proggen.

... arbeitet jemand von euch so richtig konsequent ersthaft mit public/private/protected ?

C++ verwendet man, wenn man OOP http://de.wikipedia.org/wiki/Objektorientierte_Programmierung betreiben will. Da macht spezifische Kapselung absolut Sinn. Modernere Sprachen verwenden doch noch mehr solcher Zugangsmodi.

Artchi

Richtig, Java hat sogar 4 Stufen: private, protected, default und public.