Das stimmt in dem Fall. Allerdings muss man auch hier relativieren.
Ja, deshalb habe ich das mit den skalaren RValues auch extra hingeschrieben.
Resultat: Projekt-X-const ist durchschnittlich ca. 10-15% schneller als das Projekt-X ohne const. Diese Zahl stammt nicht von mir selbst, ich zitiere hier nur.
Fakt ist, der Compiler kann sehr viel besseren Code erzeugen, da potentielle Speicherzugriffe entfallen. Ein Stichwort ist hier Cache-WB.
Naja, die 10-15% scheinen mir etwas viel. Klar sind leichte Optimierungen möglich, auch dadurch, dass konstante Ausdrücke zur Kompilierzeit ausgerechnet werden, aber im Allgemeinen werden sich die Performancegewinne durch const in Grenzen halten.
man sollte const eigentlich nur verwenden, um den benutzer einer methode/funktion vor dummen fehlern zu schützen. da bei den meisten hobbyprojekten der benutzer auch der autor ist, kann man das const meistens auch weglassen. wayne.
Du scheinst wohl noch keine grösseren Projekte angegangen zu haben. const schützt dich genauso vor deinen Fehlern wie die Benutzer einer Bibliothek. Du kannst damit eine ganze Semantik festlegen, unterschätz das Konzept der Const-Correctness nicht.
Es kann durchaus im Sinn der Implementierung sein die Parameter zu verwenden und zu ändern und die Möglichkeit sollte bestehen bleiben.
Genau.
Deshalb kann der Compiler da auch nicht optimieren, weil es sein könnte, dass die Lib absichtlich einen const Parameter übergibt, den man dann casten und verändern soll.
Dass das fragwürdiges Design ist, wurde ja schon erwähnt. Ich wüsste aber auch nicht, wie der Compiler const-qualifizierte Objekte gegenüber unqualifizierten bei einer Referenzübergabe optimieren sollte...
Aber const_cast ist ein Schlüsselwort, das sehr selten und nur mit grösster Sorgfalt eingesetzt werden sollte. In den allermeisten Fällen ist es durch sauberes Design hinfällig. C++ erlaubt genauso Casts zwischen Zeigern auf double-Arrays und std::string, trotzdem rechtfertigt das nicht deren Einsatz.