Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

41

25.06.2009, 23:35

Zitat von »"dot"«

Das stimmt in dem Fall. Allerdings muss man auch hier relativieren.
Ja, deshalb habe ich das mit den skalaren RValues auch extra hingeschrieben. ;)

Zitat von »"FalkT"«

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.

Zitat von »"ChrisJ"«

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.

Zitat von »"David_pb"«

Es kann durchaus im Sinn der Implementierung sein die Parameter zu verwenden und zu ändern und die Möglichkeit sollte bestehen bleiben.
Genau. :)

Zitat von »"Helmut"«

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.

Helmut

5x Contest-Sieger

Beiträge: 692

Wohnort: Bielefeld

  • Private Nachricht senden

42

26.06.2009, 16:01

Zitat von »"dot"«



C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
void blob(const int& x)
{
  int* a = const_cast<int*>(&x);

  *a = 10;

  if (x == 5)
  {
    // ...

  }
}


Sowas is undefiniert...
Nein, wie gesagt, das ist nur undefiniert, wenn der Integer, auf den x zeigt, konstant deklariert wurde. Schau nochmal bei "10.2.7.1 The C++ Programming Language" vorbei.

Aber ich hab hier irgendwie keine Lust mehr zu. Können wir uns nicht darauf einigen, dass wir jetzt alle brav const benutzen und es gut sein lassen?:)

Ciao
Sei stets geduldig gegenüber Leuten, die nicht mit dir übereinstimmen. Sie haben ein Recht auf ihren Standpunkt - trotz ihrer lächerlichen Meinung. (F. Hollaender)