Constness-Aushebelung verhindern

[Ich bin Dawg]

Ich habe eine Klasse Inside , von der sich ein Member in einer anderen Klasse Outside befindet:

class Inside
{
public:

	void SetNumber(int number)
	{
		m_Number = number;
	}

	int GetNumber() const
	{
		return m_Number;
	}

private:

	int m_Number;
};

class Outside
{
	// ...

private:

	Inside m_Inside;
}

Die äußere Klasse soll den inneren Wert nun schreibgeschützt zur Verfügung stellen:

class Outside
{
public:

	const Inside &GetInside() const
	{
		return m_Inside;
	}

	// ...
}

An sich funktioniert das ganz gut:

Outside outside;

Inside &inside = outside.GetInside();
	// Korrekterweise ein Fehler: Referenz muss konstant sein.

const Inside &inside = outside.GetInside();
	// Alles OK

inside.SetNumber(5);
	// Korrekterweise ein Fehler.

cout << inside.GetNumber();
	// Alles OK

Jetzt hab ich nur ein Problem:

(const_cast<Inside &>(inside)).SetNumber(5);
	// Aaah! Mieser Bastard!

cout << outside.GetInside().GetNumber();
	// Der Wert wurde tatsächlich verändert.

Wie kann ich das verhindern?

[pumuckl]

Ich bin Dawg schrieb:

Jetzt hab ich nur ein Problem:

(const_cast<Inside &>(inside)).SetNumber(5);
	// Aaah! Mieser Bastard!

cout << outside.GetInside().GetNumber();
	// Der Wert wurde tatsächlich verändert.

Wie kann ich das verhindern?

Garnicht. Wenn jemand böswillig an deinen Code rangehen möchte und mit Methoden arbeitet die potentiell undefiniertes Verhalten auslösen, dann ist er auch bereit, einen reinterpret_cast oder ähnlich fiese Dinge zu benutzen und dagegen kannst du auch nichts tun. Du hast mit der Schaffung des Interfaces genug getan um vernünftige Klienten vor Fehlern zu bewahren, mehr ist nicht drin.

[Dawg]

Wozu gibt es dieses const_cast eigentlich? Was haben die sich dabei gedacht? Das ist ja kein Hack im Stil von

#define private public

sondern ein reservierter Begriff.

[pumuckl]

manchmal kriegt man const objekte und weiß dass sie eigentlich nicht const sind - in dem Fall kann man const_cast anwenden. Oder eben andersrum, man weiß dass eine Funktion ein Objekt nicht verändert, auch wenn ihr interface das nicht garantiert. Kommt z.B. vor wenn jemand vergessen hat ein const in einer Funktionssignatur anzugeben oder wenn eine Methode fälschlicherweise nicht als const deklariert ist. const_cast ist fast immer nur eine Reparatur, und wenn man es sieht heißt das im Normalfall "hier stimmt was nicht".

[Artchi]

Matürlich ist da mehr drin! Er brauch nur eine Context-Klasse erstellen bzw. die Outside-Klasse ist nicht richtig designed:

class InsideContext
{
    Inside *m_inside;
public:
    int GetNumber() const
    {
        return m_inside->GetNumber();
    }
}

Das Prinzip beruht darauf, das man halt nicht das Zielobjekt zurück gibt, sondern nur deren Values. Und natürlich darf die Context-Klasse keine Set-Methoden haben!

Das machen wir in unseren Java-Projekten, um die Const-Correctness zu implementieren. Kann man auch für C++ benutzen.

Wenn man noch krasser vorgehen will, sollte man das Inside als Interface-Klasse designen und dann das konkrete Objekt als pimpl-Idiom implementieren! Weil dann weiß der User nicht mal welches konkrete Inside-Objekt dort versteckt ist, und muß zur Laufzeit raten, welcher konkrete Inside-Typ wohl im Context versteckt ist. Aber das oben gezeigte Context leistet auch schon einiges.

[Artchi]

Dawg schrieb:

Wozu gibt es dieses const_cast eigentlich? Was haben die sich dabei gedacht? Das ist ja kein Hack im Stil von

#define private public

sondern ein reservierter Begriff.

Das const ist aber kein Implementierungs-Const, sondern ein Information-Const. Naja, habe jetzt keine anderen Begrifflichkeiten zur Hand. Aber so wird es auch jeder verstehen.

Man sollte bedenken, das die Sprache nicht dafür da ist, Implementierungen zu schützen. Es geht um formalistem. Das private in Klassen soll z.B. nicht davor schützen, das jemand eine private-variable manipuliert, sondern nur das die Kapselung im OO-Sinne gewahrt wird - mehr nicht! Deshalb ist es natürlich i.O. das es const_cast gibt. Weil die Intention von const nicht bedeutet, das es eine Hochsicherheitstrackt mit ner Festung ist. Da muß was anderes her: eine CPU-Erweiterung oder OS-Feature. Weil das wäre ein Implementierungsdetail.

[Dawg]

pumuckl schrieb:

manchmal kriegt man const objekte und weiß dass sie eigentlich nicht const sind [...] wenn jemand vergessen hat ein const in einer Funktionssignatur anzugeben

Also mal wieder nur so ein Notbehelf, wenn der Programmierer des Interface Mist gebaut hat.

Artchi schrieb:

Matürlich ist da mehr drin! Er brauch nur eine Context-Klasse erstellen bzw. die Outside-Klasse ist nicht richtig designed

Das mag für das gezeigte Beispiel ganz nett sein, aber wenn ich in der Outside-Klasse Member von 10 verschiedenen Typen habe und jeder von diesen Typen hat 10 für die Außenwelt sichtbare Attribute, dann kann ich 100 zusätzliche Getter schreiben, was eine Menge Mehrarbeit ist.

Artchi schrieb:

Man sollte bedenken, das die Sprache nicht dafür da ist, Implementierungen zu schützen. Es geht um formalistem. Das private in Klassen soll z.B. nicht davor schützen, das jemand eine private-variable manipuliert, sondern nur das die Kapselung im OO-Sinne gewahrt wird - mehr nicht!

Hmm. Du hast wohl recht, aber dann finde ich die Philosophie von C++ schon etwas komisch. Gibt es denn solche Sachen auch in anderen Sprachen? Ich kann mich nicht erinnern, dass zum Beispiel in C# solche Spielereien und Aushebelungen möglich sind. (Gut, in C# gibt es das const für Referenztypen nicht, aber ich meine jetzt mal generell.) Wann erfindet endlich mal jemand eine Sprache, die in der Quellcodespezifikation so sauber wie C# ist, aber klassischen Maschinencode produziert?

[Simon2]

Ich bin Dawg schrieb:

...

...
class Outside
{
	// ...

private:

	Inside m_Inside;
public:

	const Inside GetInside() const
	{
		return m_Inside;
	}

	// ...
}

...

Funktioniert tadellos.
Natürlich bekommt der Aufrufer nun keine Änderungen des Inside-Objekts mehr mit ... aber dasselbe Problem hättest Du bei Gettern auf Elementebene - und das wäre IMHO noch schlimmer, weil bei der Kopie wenigstens einen klaren "Synchronisationspunkt" hast.

Gruß,

Simon2.

[Simon2]

Dawg schrieb:

...
Das mag für das gezeigte Beispiel ganz nett sein, aber wenn ich in der Outside-Klasse Member von 10 verschiedenen Typen habe und jeder von diesen Typen hat 10 für die Außenwelt sichtbare Attribute, dann kann ich 100 zusätzliche Getter schreiben, was eine Menge Mehrarbeit ist....

Ist auch anders noch einfacher:

Ich bin Dawg schrieb:

...

...
class Outside
{
	// ...

private:

	Inside m_Inside;
public:

	const Inside GetInside() const
	{
		return m_Inside;
	}

	// ...
}

...

Funktioniert tadellos.
Natürlich bekommt der Aufrufer nun keine Änderungen des Inside-Objekts mehr mit ... aber dasselbe Problem hättest Du bei Gettern auf Elementebene - und das wäre IMHO noch schlimmer, weil bei der Kopie wenigstens einen klaren "Synchronisationspunkt" hast.

Gruß,

Simon2.

[Dawg]

Klar, mit Kopien geht's natürlich immer. Fragt sich nur, ob das so gut/effektiv ist, jedesmal die Daten alle komplett rüberzuschaufeln.

[Dawg]

Denk mal nur an irgendwelche vector-Variablen oder map oder list, die ja sonst wieviel Einträge haben können.

[asc]

Dawg schrieb:

Ich kann mich nicht erinnern, dass zum Beispiel in C# solche Spielereien und Aushebelungen möglich sind. (Gut, in C# gibt es das const für Referenztypen nicht, aber ich meine jetzt mal generell.)

Gerade deine Einschränkung zeigt, das C# nur deshalb als so sauber erscheint, weil man sich um vieles gedrückt hat. Und gerade const vermisse ich durchaus in C# & Co.

[asc]

Dawg schrieb:

...dann kann ich 100 zusätzliche Getter schreiben, was eine Menge Mehrarbeit ist.

Gerade diese "Faulheit" aufgrund Mehraufwandes auf bestimmte Möglichkeiten zu verzichten, führt in einigen Projekten zu ernsthaften Problemen. Und das Gefrickel außen herum um die Faulheit zu überdecken benötigt anschließend meist mehr Zeit.

[Simon2]

Dawg schrieb:

Klar, mit Kopien geht's natürlich immer. Fragt sich nur, ob das so gut/effektiv ist, jedesmal die Daten alle komplett rüberzuschaufeln.

Das wäre bei der getter-Methode nicht prinzipiell anders (nur, dass Du die Elemente einzeln kopierst - dafür aber ggf. öfter).

Außerdem frage ich mich langsam, was Du willst:
* C++ hat ein bestehendes und funktionierendes System, um ungewollte Änderungen zu verhindern (const).
* Es bietet für Diejenigen, die die Kontrolle lieber selbst haben wollen, einen Weg dazu an (überlässt dabei natürlich dem Programmierer selbst die Verantwortung)

Und Du hättest gern eine Möglichkeit, die
a) ein Sprachfeature für genau den definierten Zweck unterbindet aber
b) weder beim Programmieren noch zur Laufzeit Aufwand erzeugt?
Darin sehe ich aber kein "Schwäche des const-Konzepts", sondern eine Stärke.

Was hättest Du erwartet? Ein "non_const_castable_const" ?

Gruß,

Simon2.

[Nexus]

Simon2 schrieb:

Außerdem frage ich mich langsam, was Du willst:
* C++ hat ein bestehendes und funktionierendes System, um ungewollte Änderungen zu verhindern (const).
* Es bietet für Diejenigen, die die Kontrolle lieber selbst haben wollen, einen Weg dazu an (überlässt dabei natürlich dem Programmierer selbst die Verantwortung)

Genau. C++ bietet dem Programmierer sehr viel Freiheit. Und damit kommt bekanntlich Verantwortung. Wenn ich weiss, was ich tue, soll mich die Sprache nicht bevormunden. Ich halte mich in dem Fall für erfahren genug, um ein Sprachmittel richtig einzusetzen. Falls ich das nicht vertreten kann, lasse ich die Finger davon -- das stellt schliesslich auch kein Problem dar. Wenn ich mir sicher bin, dass ich auf ein Array nur innerhalb der Grenzen zugreife -- wieso sollte ich für Laufzeitchecks bezahlen, die ich nicht brauche?

Sprachen wie Java gehen hier einen anderen Weg: Sie versuchen, idiotensicher zu sein. Auf eine Weise ist das gut, weil es offenbar weniger Fehlerquellen gibt, andererseits zahlt man einen gewissen Preis, und das ist nicht nur Performance. Gewisse Operationen werden einem in Java grundsätzlich erschwert bis verunmöglicht (laut Fanboys braucht man diese in einer "High-Level-Sprache" natürlich nie). Möglichkeiten wie Operatorüberladung hat man nicht, weil die mehrfache Bedeutung eines Operators verwirren kann (was ja bei Methoden mit gleichem Namen nie passiert, siehe kontextunabhängig klare Bedeutung von add() ). Das finde ich etwas schade, ansonsten mag ich Java eigentlich.

Doch in gewisser Hinsicht habe ich ein grundsätzliches Problem mit der Philosophie, alles an einer Programmiersprache wasserdicht zu gestalten -- selbst abgesehen von der Freiheit, die man dafür hergeben muss. Meiner Meinung nach führt jene Einstellung dazu, dass man weniger erfahren sein muss, um lauffähigen (nicht zwingend sinnvollen) Code zu schreiben. Dadurch hat man Resultate, die zwar irgendwie funktionieren und vielleicht sogar gut aussehen, aber der Code ist ein Graus. Und das kann durchaus ein Problem darstellen, wenn beispielsweise die Wartung ein Thema wird. In C++ wird man viel eher gezwungen, die Sprachmittel gleich richtig zu lernen. So schätze ich die Situation jedenfalls ein.

Langer Rede kurzer Sinn: Dawg, schreibe die Klasse und insbesondere die Schnittstelle so, dass offensichtliche Fehler vermieden werden. Halte dich dabei an gängige Konventionen und schreibe intuitiven Code. Versuche aber nicht, den Code vor Missbrauch oder Idiotie zu schützen, denn das wird dir nicht gelingen. Wenn der Benutzer Freude daran hat, das const wegzucasten, soll er das tun und die Konsequenzen tragen. Man sollte Code im Allgemeinen auch nicht für Leute vorsehen, welche die Sprache nicht beherrschen. Das ist übrigens auch in C# oder Java so, dort gibt es eben andere Dinge, die man falsch anwenden kann (gerade fehlende Const-Correctness eröffnet neue Fehlermöglichkeiten).

[Dawg]

asc schrieb:

Gerade deine Einschränkung zeigt, das C# nur deshalb als so sauber erscheint, weil man sich um vieles gedrückt hat. Und gerade const vermisse ich durchaus in C# & Co.

const vermisse ich in C# auch. Aber nicht die Möglichkeit des Aushebelns von const.

asc schrieb:

Gerade diese "Faulheit" aufgrund Mehraufwandes auf bestimmte Möglichkeiten zu verzichten, führt in einigen Projekten zu ernsthaften Problemen. Und das Gefrickel außen herum um die Faulheit zu überdecken benötigt anschließend meist mehr Zeit.

Wenn die Sprache ordentlich definiert wäre, hätte man bei meinem Problem beides: Man hätte die eleganteste Lösung und den wenigsten Aufwand: Die Rückgabe einer const-Referenz: Lesezugriff erlaubt, Schreibzugriff nicht möglich. So, wie ich es haben wollte.

Simon2 schrieb:

Dawg schrieb:

Klar, mit Kopien geht's natürlich immer. Fragt sich nur, ob das so gut/effektiv ist, jedesmal die Daten alle komplett rüberzuschaufeln.

Das wäre bei der getter-Methode nicht prinzipiell anders (nur, dass Du die Elemente einzeln kopierst - dafür aber ggf. öfter).

Wieso? Bei einer Rückgabe einer const-Referenz würde ich doch nur jeweils die Speicheradresse, also ein simples int, kopieren. Bei einer echten Kopie habe ich bei einem vector<double> mit 100 Einträgen schonmal 800 Byte statt nur vier.

Simon2 schrieb:

Außerdem frage ich mich langsam, was Du willst:
* C++ hat ein bestehendes und funktionierendes System, um ungewollte Änderungen zu verhindern (const).
* Es bietet für Diejenigen, die die Kontrolle lieber selbst haben wollen, einen Weg dazu an (überlässt dabei natürlich dem Programmierer selbst die Verantwortung)

Dann frage ich mich, wieso wir überhaupt noch private und protected haben. Wieso nicht gleich überall public nehmen. Für den Programmierer, der gern die Kontrolle hat.

Simon2 schrieb:

Und Du hättest gern eine Möglichkeit, die
a) ein Sprachfeature für genau den definierten Zweck unterbindet aber
b) weder beim Programmieren noch zur Laufzeit Aufwand erzeugt?
Darin sehe ich aber kein "Schwäche des const-Konzepts", sondern eine Stärke.

Was hättest Du erwartet? Ein "non_const_castable_const" ?

Nein, ich brauch kein weiteres Sprachfeature. Man hätte nur den const_cast weglassen müssen und alles wäre gut. Es hat ja schließlich einen Grund, wieso etwas als const zurückgegeben wird. Da ist es doch arschig, wenn der Benutzer das wieder rückgängig machen kann.

Nexus schrieb:

Genau. C++ bietet dem Programmierer sehr viel Freiheit. Und damit kommt bekanntlich Verantwortung. Wenn ich weiss, was ich tue, soll mich die Sprache nicht bevormunden.

Was hat es mit Bevormundung zu tun, wenn ich jemanden daran hindere, die Klasse einer anderen Person nicht zweckzuentfremden? Wenn ich eine Funktionsbibliothek schreibe, dann sollen die Benutzer nicht manuell in meinen internen Daten rumspielen können. Wie gesagt, dann könnte man auch auf Zugriffsmodifizierer verzichten.

Nexus schrieb:

Versuche aber nicht, den Code vor Missbrauch oder Idiotie zu schützen, denn das wird dir nicht gelingen.

Das mit der Idiotie sehe ich ein, das mit dem Missbrauch stößt mir immer noch etwas auf. Denn dann sehe ich wirklich keinen Grund mehr, wieso man nicht generell alle Attribute public machen soll. Der erfahrene Programmierer weiß, daß Attribute bei gutem Code niemals als public gedacht sind, wird sie also auch nicht versehentlich benutzen. Aber der, der sich nicht "bevormunden" lassen will und der Spaß daran hat, kann nach Lust und Laune auf die Rohdaten zugreifen. Aber da hat C++ dem Benutzer komischerweise nicht die Freiheit gelassen. (Mal abgesehen vom #define private public Makro, an das die Erfinder aber, schätze ich mal, nicht gedacht haben.)

[unskilled]

"die Sprache ordentlich definiert wäre, hätte man bei meinem Problem beides: Man hätte die eleganteste Lösung und den wenigsten Aufwand: Die Rückgabe einer const-Referenz: Lesezugriff erlaubt, Schreibzugriff nicht möglich. So, wie ich es haben wollte."
1. ist const_cast ab und an (zur vermeidung von code-duplikation) recht hilfreich und
2. kann man jeden code irgendwie aushebeln, wenn man mit ihm arbeitet - das ist nun mal so und wird auch immer so bleiben...

z.bsp. kommt man eben auch an member, die nicht mal mittels getter erreicht werden können, indem man (in der praxis, im standard steht das nirgendwo) ne adresse auf den ptr der instanz addiert etc...

oder siehe das verbieten des adress-op`s -> boost::address_of

bb

[Nexus]

Dawg schrieb:

Was hat es mit Bevormundung zu tun, wenn ich jemanden daran hindere, die Klasse einer anderen Person nicht zweckzuentfremden? Wenn ich eine Funktionsbibliothek schreibe, dann sollen die Benutzer nicht manuell in meinen internen Daten rumspielen können. Wie gesagt, dann könnte man auch auf Zugriffsmodifizierer verzichten.

Wieso sollte man auf const_cast verzichten und dem Programmierer die Möglichkeit nehmen, es an Stellen einzusetzen, wo es wirklich gebraucht wird? const kannst du noch auf etwa fünf andere Arten aushebeln als mit einem Cast, die aber allesamt dreckig sind und undefiniertes Verhalten hervorrufen. Da schafft man lieber ein Sprachmittel, das speziell für diesen Fall konzipiert ist und ein sicheres Hantieren ermöglicht (unter gewissen Einschränkungen). Glaub mir, der böswillige Missbraucher (ich sehe übrigens immer noch nicht, welchen Nutzen man davon hat) würde sich bei Fehlen von const_cast was anderes ausdenken und mit Sicherheit was finden.

Ausserdem: const_cast ist zwar eine Errungenschaft von C++, aber dient nur dazu, den Klammercast aus C weniger gefährlich zu machen, indem die Funktionalität auf drei Operatoren verteilt wird.

Dawg schrieb:

Das mit der Idiotie sehe ich ein, das mit dem Missbrauch stößt mir immer noch etwas auf. Denn dann sehe ich wirklich keinen Grund mehr, wieso man nicht generell alle Attribute public machen soll.

Du vermischst jetzt etwas. Es gibt grundsätzlich zwei Haltungen:

1. Sprachmittel unterstützen den vernünftigen Benutzer, Fehler einzuschränken und erledigen ihren Job auf eine sehr gute Weise. Nach Herb Sutter "protection against Murphy".
2. Sprachmittel sind auf einen böswilligen Programmierer ausgelegt und verunmöglichen falsche Benutzung. Gleichzeitig schränken sie aber die Freiheit derer ein, die gewisse Operationen tatsächlich benötigen. Nach Herb Sutter "protection against Machiavelli".

Was du machst, ist beide in den gleichen Topf zu werfen. Es ist offensichtlich, dass private , const und Co. auf Ansatz 1 ausgelegt sind und es ist ebenso deutlich, dass bei vernünftiger Benutzung nie Probleme damit entstehen.

Wenn dir Punkt 2 eher zusagt, bist du in einer anderen Programmiersprache wie Java wahrscheinlich besser aufgehoben. Du musst dich mit der Philosophie von C++ zurecht finden, ansonsten wirst du immer frustriert programmieren.

[asc]

Dawg schrieb:

const vermisse ich in C# auch. Aber nicht die Möglichkeit des Aushebelns von const.

Was a) undefiniertes Verhalten herbeiführt und b) in wohl jeder Sprache mit Zeigern möglich ist (und sei es durch Umwege). const ist erst später in die Sprache eingeflossen, so das es schwerlich möglich ist eine saubere Lösung anzubieten (Denk dran das C++ etwa 30 Jahre alt ist).

Dawg schrieb:

Wenn die Sprache ordentlich definiert wäre, hätte man bei meinem Problem beides:

Dann ist KEINE mir bekannte Sprache ordentlich. In jeder mir bekannten Sprache kann man irgendwelche Prinzipien durch irgendwelche "Hacks" aushebeln. Ich kenne übrigens kaum Code in der const_cast verwendet wird, und nur dann, wenn auf Bibliotheken zugegriffen wird, die keine const correctness umsetzen. Ein Programmierer sollte auch mitdenken können.

Dawg schrieb:

Wieso? Bei einer Rückgabe einer const-Referenz...

...baust du Seiteneffekte ein, die unter Umständen problematischer sind, als der Kopieraufwand. Was ist, wenn ich diese Rückgabe als const reference binde, und dann das Objekt ändere. Prompt ist der Wert ggf. auch wieder geändert. Man sollte zumindest bei Referenzrückgaben sehr stark aufpassen.

Und gerade du, der du saubere Programmierung erzwingen willst, riskierst wieder die Fehlbedienung?

Dawg schrieb:

Nein, ich brauch kein weiteres Sprachfeature. Man hätte nur den const_cast weglassen müssen und alles wäre gut...

...und alten Code den man nicht verändern kann (oder nicht die Zeit bekommt), kann man anschließend nur noch verwenden wenn man im neuen ebenso const weglässt... Nein, Danke.

[Kahino]

Warum Getter für interne Objekte schreiben wenn man auch eine konstante Referenz zrückgeben kann?
Könnte man sich fragen, wurde hier auch mal getan.

Ob einfach oder nicht, Fakt ist, gibt ein internes Objekt zurück, in welcher Form auch immer, weicht du die Datenkapselung auf und das man damit dann Mist bauen kann musst du mit Rechnen.

Aber für die Getter sprechen auch noch anderek Faktoren als dieses Const-Problem.
Wenn du jetzt dein inneres Objekt veränderst und eine gewisse Methode eventuell ein Argumenterwartet, musst du nun nicht nur das Objekt anpassen das dieses Objekt enthält, sondern auch noch jede Stelle wo du dir diese Referenz zurückgeben lässt.

@Freiheit und Kontrolle

Freiheit und Kontrolle ist schön und gut, doch sollte sie sich darin äußern das ich selbst entscheide In wie Weit mein Code manipulierbar ist und nicht in wie weit man vorhandene Sprachmittel umgehen kann damit ich Selber selbst meine eigenen Entscheidungen unterlaufen kann oO.
So ein Prinzip nennt sich nicht frei sondern fehleranfällig.
Datenkapselung, Objektorientierung, Typprüfung usw. wurden nicht umsonst eingeführt, eben weil der Mensch nicht perfekt ist.
Perfekte Wesen brauchen kein Konst oder Datenkapselung, die machen keine Fehler.
Fehler sind jedoch menschlich.
Die Freiheit einer sprache sollte sich demnach darauf beziehen in wie weit man sich selbst zu schützen gedenkt. Das hat nichts mit Bevormundung durch die Sprache zu tun.
Möchte man keinen Schutz benutzt man halt nur public und lässt das const und unterlässt auch sonst alle möglichen Absicherungen.

Sieht man das mit der Manipulation von internem von außen nicht so eng, macht man halt das der Konstanten Referenz als Rückgabewert ansonsten getter auf die einzelnen Elemente. Das ist der Punkt mit der Verantwortung.

Eine Sprache deren Sprachmittel einzig und alleine zur Show dienen ist so, als würde sich eine schwache kleine Person darüber freuen endlich tun und lassen zu können was man möchte weil es plötzlich keine Gesetze mehr gibt und keiner mehr darauf achtet ob irgendwelche Regeln eingehalten werden.
Dass diese Person seinen Kram zu seiner Zufriedenheit erledigt und nicht von anderen Leuten aufgemischt wird ist dann seine "Freiheit" und was genau passiert liegt in seiner Verantwortung

----------------------------------------

Das private in Klassen soll z.B. nicht davor schützen, das jemand eine private-variable manipuliert, sondern nur das die Kapselung im OO-Sinne gewahrt wird

Ich wollte hier eigentlich keine konkreten Aussagen behandeln aber ... wie bitte?

Die Kapselung im OO sinne beinhaltet doch, dass man sie von außen nicht ändern kann, wie kann private dann nciht dafür verantwortlich sein?

[Artchi]

Kahino schrieb:

Das private in Klassen soll z.B. nicht davor schützen, das jemand eine private-variable manipuliert, sondern nur das die Kapselung im OO-Sinne gewahrt wird

Ich wollte hier eigentlich keine konkreten Aussagen behandeln aber ... wie bitte?

Die Kapselung im OO sinne beinhaltet doch, dass man sie von außen nicht ändern kann, wie kann private dann nciht dafür verantwortlich sein?

Hast du dir mein Posting insgesamt betrachtet? Anscheinend nicht, sonst würdest du feststellen, das ich von dem Schreibschutz auf Implementierungsebene geschrieben habe. Nochmal für dich: das private ist nicht für Implementierungs-Hiding zuständig! Da kannst du dich auf den Kopf stellen, das wird deshalb nicht anders. Das private ist ein reiner Formalismus auf OO-Sprachebene und der User bekommt deshalb lediglich beim Kompilieren die Meldung "Sorry, aber da darfst du nicht zugreifen!". Mehr nicht. Das private steht ja nach dem Kompilieren nirgends im Speicher...