Ich schreibe eine Klasse, die eine veraltete C-API umschließt, die ein Hardwaregerät steuert. In einem vereinfachten Beispiel könnte ich etwa Folgendes haben:
%Vor% Die Klasse selbst hat keinen bitweisen Zustand; Daher könnte ich set_request() als const deklarieren und der Compiler wäre damit zufrieden. Aber wäre dies aus semantischer Sicht der richtige Ansatz, da das beobachtbare Verhalten des Objekts beeinflusst wird? (d. h. das eingekapselte Hardware-Gerät hat sehr viel hat einen Zustand.)
Ich glaube, dass const logisch const-ness widerspiegeln sollte, unabhängig von der internen Darstellung. Nur weil Ihr Objekt nur einen Zeiger auf etwas enthält, das sich ändert, bedeutet das nicht, dass alle Ihre Mitgliedsfunktionen const sein sollten.
C ++ hat sogar das mutable -Konzept für die interne Repräsentation, das geändert werden muss, auch wenn das Objekt konzeptionell nicht funktioniert. Das Schlüsselwort const ist eindeutig nicht dazu gedacht, "bitweise" Konstanz darzustellen.
Wenn der Status geändert wird, sollte nicht const sein. Die Tatsache, dass der fragliche Zustand remote ist (d. H. In einem kontrollierten Gerät), ändert das nicht.
Ein nützlicher Test ist:
könnte Code mit nur const Zugriff auf die Geräteinstanz interferieren mit der Operation von Code mit nicht const access
Grundsätzlich bedeutet const access, dass du effektiv ein Beobachter bist. Hier sieht es so aus, als ob der Code, der set_request(...) zur Zeit T1 und dann get_response() zur Zeit T3 aufruft, ernsthaft geschraubt wird, wenn ein vermeintlicher Beobachter set_request() mit verschiedenen Parametern zur Zeit T2 anruft. Aus diesem Grund sollte set_request(...) für Beobachter nicht zugänglich sein - es sollte nicht const sein.
(Es gibt Vorbehalte gegenüber dem Test - zB wenn ein const "observer" eine Sperre benötigt, kann er offensichtlich die nicht const Verwendung von einem anderen Thread aus einer Timing-Perspektive beeinflussen, sollte dies jedoch nicht von einer funktionalen tun - aber es ist ziemlich offensichtlich, wie man das in Ihre Analyse einbezieht).
Wie andere Typ- und Mitgliedsqualifikationen (z. B. öffentlich, privat, virtuell) drückt const sowohl die Absicht als auch die Sprachsemantik (d. h. Sicherheitsmerkmale) aus, die diese Absicht unterstützen. In diesem Fall würde die Intention kontraintuitiv erscheinen, selbst wenn die zugrundeliegende Semantik sicher wäre. Ich würde es nicht tun.