Constness-Aushebelung verhindern

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

[Simon2]

Dawg schrieb:

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

Aber so ist es doch auch: Man kann eine const-Referenz zurückgeben.

Dawg schrieb:

...

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

Wie Du zwischen meinem Post und Deinem anscheinend vergessen, dass an dieser Stelle über die "getter-Variante" geredet wurde, die Artchie vorgestellt hat, die Dir aber zu aufwendig war.

Dawg schrieb:

...Dann frage ich mich, wieso wir überhaupt noch private und protected haben. Wieso nicht gleich überall public nehmen. ...

Vielleicht solltest Du mal über den Unterschied zwischen
- dem Vorhandenseins eines "Notausknopfs" und
- der Nichtexistenz der Maschine
nachdenken.
Ich persönlich wäre (auch nach Dekaden der Programmiererfahrung) nie derart überzeugt von meiner eigenen Unfehlbarkeit und Weitsicht, "Notausknöpfe" prinzipiell verbieten zu wollen.

Dawg schrieb:

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

Und Du glaubst, const_cast wäre nur durch reinen Zufall in den Standard gerutscht?
Bloß weil Du ihn noch nie gebraucht hast, bedeutet es nicht, dass er überflüssig ist - es bedeutet eher, dass es noch Ecken in der Programmiererwelt gibt, in die Du noch nicht vorgedrungen bist.
Es ist ein sehr gefährliches Werkzeug, dass aber in bestimmten Ausnahmesituationen gebraucht wird.

Gruß,

Simon2.

[Kahino]

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.

Tja, auch wenn ich alles zitiere ändert sich nichts und das glücklicherweise auch ohne mich auf den Kopf stellen zu müssen.

Was spielt das für eine Rolle ob irgendwo im Speicher private steht oder nicht?
Was du vor der Kompilierung machs soll ja schließlich bestimmen wie das Ergebnis nach der Kompilierung arbeitet.

Die Objektorientierung ist dabei lediglich ein optionales Abstraktionsmodell das man Verwenden kann oder auch nicht.
Solche Konzepte als Formalismus abzustempeln ist nicht falsch, doch darf man nicht vergessen, dass es sich bei diesem Formalismus(unabhängig von Objektorientierung oder irgendeiner spezifischen Sprache) nunmal um DAS Werkzeug handelt um die gewünschen Arbeitsvorgänge zu beschreiben.

Schließlich soll ja alles wohl definiert und keine Glückssache sein oO, (man stelle sich sowas mal in der Mathematik vor ).
Unstimmigkeiten kann es immer wieder mal geben, doch wenn man bei irgendwas behaupten kann das Ergebnis ist garantiert anders als man es vorher definiert hat, läuft da gehörig was schief und so wird es ja wohl nicht sein.
Und das gilt sicherlich auch für einige andere Gebiete, fernab der Programmierung.

In kurz:
Habe sehr wohl deinen ganzen Post gelesen, Jedoch sind Meinungen wie etwas sein sollte alles andere als absolut.

[Simon2]

Kahino schrieb:

...Was spielt das für eine Rolle ob irgendwo im Speicher private steht oder nicht?...

In dem Zusammenhang hatte ich es so verstanden: Der "Zugriffsschutz", den "private" bietet, ist (relativ problemlos) zu umgehen - er schützt also nicht gegen "Hacks"/"Macchiavelli"/... .
Das hätte man anders implementieren können, wenn "...private im Speicher steht..." und dort durch irgendwelche Laufzeitmechanismen (Runtime, OS, CPU, ....) geprüft/sichergestellt wird.

Im Zusammenhang der Diskussion ist das wesentlich, weil der Threadersteller gerne ein "un-hackbares const" gehabt hätte und er auf Gegenargumente einen Vergleich zu "private" zog.

Gruß,

Simon2.

[otze]

Nochmal zum const_cast: Der ist nur und alleine dafür da, um nicht const-korrekte Klassen mit const-korrekten Klassen verwenden zu können. Das heißt, wenn wir wissen, dass eine Methode eines Objektes das Objekt nicht ändert, aber leider nicht als const klassifiziert wurde, dann dürfen wir den const_cast machen. andernfalls nicht.

[knivil]

otze schrieb:

Nochmal zum const_cast: Der ist nur und alleine dafür da, um nicht const-korrekte Klassen mit const-korrekten Klassen verwenden zu können. Das heißt, wenn wir wissen, dass eine Methode eines Objektes das Objekt nicht ändert, aber leider nicht als const klassifiziert wurde, dann dürfen wir den const_cast machen. andernfalls nicht.

Aehmmm ... naja ... hmmm ... Wenn ich z.B. in meiner Datenhaltungsschicht eine Suchfunktion habe, die intern einen Index veraendert und anschliessend wieder zuruecksetzt, dann kann ich das const wegcasten, damit die Methode trozdem const ist. Eine andere Moeglichkeit ergibt sich durch das Schluesselwort mutable.

Bei diesen und Aehnlichem verweise ich gern auf: http://www.parashift.com/c++-faq-lite/classes-and-objects.html#faq-7.7 . Const hilft, aber schuetzt nicht vor Fehler.

[Kahino]

In dem Zusammenhang hatte ich es so verstanden: Der "Zugriffsschutz", den "private" bietet, ist (relativ problemlos) zu umgehen - er schützt also nicht gegen "Hacks"/"Macchiavelli"/... .
Das hätte man anders implementieren können, wenn "...private im Speicher steht..." und dort durch irgendwelche Laufzeitmechanismen (Runtime, OS, CPU, ....) geprüft/sichergestellt wird.

Im Zusammenhang der Diskussion ist das wesentlich, weil der Threadersteller gerne ein "un-hackbares const" gehabt hätte und er auf Gegenargumente einen Vergleich zu "private" zog.

Jo, ersteinmal kompiliert ist das Ergebnis einfach nur ein Block Daten den man halt beliebig manipulieren kann, vorausgesetzt man hat die Zugriffsrechte auf die Datei. Doch das man von außen nun diesen Kram verändern kann hat das nichts damit zu zun wie das zu manipulierende Programm bei Ausführung selbst arbeitet.
Denn dies hängt ja, wenn man bei dieser Formulierung bleiben möchte, vom verwendeten Formalismus ab mit dem man das Verhalten umschreibt.
Und wenn wir uns über Mittel der Formulierungsebene unterhalten ist das ja auch die Ebene um die es geht.
Also bei der Frage ob man Elemente der Formulierungsebene durch spezifikationen in der Selben Formulierungsebene in welcher Art auch immer manipulieren kann bzw. nicht kann/ nicht können sollte spielen halt nur Regeln der Formulierungsebene Eine Rolle.

Wenn man ein Auto baut kümmert man sich vielleicht um die Frage wie man verhindert, dass die internen Bauteile nicht den Benzintank aufreißen.
Würde in einem Autodesigne ein Spitzer Eisenstab vorm Bezintank angelegt der nach vorne gerammt wird soballd man losfährt, würde dieses Designe die Qualitätsprüfung niemals überstehen, somit nicht konstruiert sondern überarbeitet werden.
Doch beduetet dies ja nicht, das der Besitzer eines bereits konstruierten Autos sowas nicht vielleicht lustig finden könnte und dies dann selbst einbaut oder vielleicht einfach ein Unfall passiert.
Natürlich kann das Auto auf Grund einer unsauberen Fertigung auch explodieren, ungereimtheiten gibt es halt immer wieder mal
unabhängig davon ob jetzt einfach ein Fehler auftrag oder die Qualitätskontrolle irgendwie umgangen wurde.

Mal so als kleine spontane Analogie :xmas2:
ungeprüft ob dies jetzt so 100 prozentig passt.