spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Dass const ein Hint zur Optimierung für den Compiler sein kann ist ein angenehmer Nebeneffekt, nicht aber der alleinige Sinn von const...

Const correctness ist weder eine low level Optimierung noch kostet sie Entwicklungszeit (im Gegenteil, sie spart evtl. sogar noch viel Zeit beim debuggen, vielleicht sogar gerade in Zeiten von Mehrkern CPUs. Hatte selber eben erst einen Fall wo ein einzelnes fehlendes const viele Studenten, deren Fähigkeiten wohl etwas unter denen des durchschnittlichen Hobbyprogrammierers liegen, dazu veranlasst hat ohne mit der Wimper zu zucken lustige Bugs zu bauen und dann viele Stunden und im Endeffekt auch Punkte bei der oft erfolglosen Fehlersuche draufgegangen sind). Const correctness gehört ganz normal zu den grundlegenden Konzepten von C++ so wie z.B. Exceptions oder Polymorphie. Für jemanden der die Sprache beherrscht stellt sich imo jedenfalls nicht die Frage ob er ein Sprachmittel einsetzt, sondern wann und wie.

Wie sieht es überhaupt hier mit aus:

Glaube dafür könnte man const_cast gut benutzen...(aber ist es den auch für Pointer in Ordung?)

Zitat von »"kiba"«

Wie sieht es überhaupt hier mit aus:

	C-/C++-Quelltext
1 2 3 4	C::C(const A* a,const B& b): m_a(const_cast<a*>(a)), m_b(b) {}

Glaube dafür könnte man const_cast gut benutzen...(aber ist es den auch für Pointer in Ordung?)

Wieso übergibst du dann nicht einfach den Zeiger auf ein nicht konstantes A?

Ich frag ja nur ob das so in Ordung ist mit den const_cast, da man bei const Parameter sixcher gehen kann das diese nicht verändert werden.

Zitat von »"kiba"«

Glaube dafür könnte man const_cast gut benutzen...(aber ist es den auch für Pointer in Ordung?)

Warum willst du das const da wegcasten!? Der Benutzer gibt dir einen const A* und du machst dir einfach einen A* draus, kannst a dann also verändern obwohl der Benutzer denkt dass du es nicht kannst!?

Zitat von »"FalkT"«

Zitat von »"WhiteMike"«

Gibt es da nicht diesen Tipp, dass man an jeder möglichen Stelle ein const setzen sollte, wo es reinpasst?

Hast sich hier jemand überhaupt gefragt warum man das machen sollte.
Klar ist es praktisch wenn man nichts ändern kann etc., doch steckt mehr dahinter ?

Die Antwort ist ja !

Man nehme ein Projekt X ohne const-Funktionen, dann schreibt man es um, so dass alles was gut und sinnvoll ist auch const ist.

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.

Mag natürlich früher noch wichtiger gewesen sein als heute.
Man ist jedoch immer wieder überrascht, was der moderne 4er-GCC doch alles wegoptimiert. Je nach Compiler bringt const dementsprechend unterschiedliche Speed-Vorteile.

Hi,
hast du dafür Quellen? Ich halte das nämlich für ziemlich großen Quatsch.. const kann nämlich weggecastet oder mit mutable umgangen werden, der Compiler kann also bei Libcalls nicht davon ausgehen, dass ein übergebenes Objekt unverändet bleibt. Und bei moduleigenen Funktionen kann der Compiler genauso gut ohne const herausfinden, ob ein Objekt verändert wird.
Das ist natürlich kein Grund const zu meiden.

Ciao

Zitat von »"dot"«

Zitat von »"kiba"«

Glaube dafür könnte man const_cast gut benutzen...(aber ist es den auch für Pointer in Ordung?)

Warum willst du das const da wegcasten!? Der Benutzer gibt dir einen const A* und du machst dir einfach einen A* draus, kannst a dann also verändern obwohl der Benutzer denkt dass du es nicht kannst!?

Weil sonst eine Kompielerfehler kommt, den man kann ja nicht const A* zu A* convertieren.

Zitat von »"kiba"«

Zitat von »"dot"«

Zitat von »"kiba"«

Glaube dafür könnte man const_cast gut benutzen...(aber ist es den auch für Pointer in Ordung?)

Warum willst du das const da wegcasten!? Der Benutzer gibt dir einen const A* und du machst dir einfach einen A* draus, kannst a dann also verändern obwohl der Benutzer denkt dass du es nicht kannst!?

Weil sonst eine Kompielerfehler kommt, den man kann ja nicht const A* zu A* convertieren.

Das Problem liegt wo anders: Das Problem ist dass dein m_a kein const A* ist. const_cast ist nicht einfach nur ein Mittel um falschen Code zum kompilieren zu zwingen...

Zitat von »"Helmut"«

Hi,
hast du dafür Quellen? Ich halte das nämlich für ziemlich großen Quatsch.. const kann nämlich weggecastet oder mit mutable umgangen werden, der Compiler kann also bei Libcalls nicht davon ausgehen, dass ein übergebenes Objekt unverändet bleibt.

Natürlich kann man const wegcasten. Allerdings braucht das den Compiler nicht zu kümmern. Du kannst bei deinem Auto auch die Räder absägen, dann den Hersteller auf Garantie zu klagen ist wieder eine andre Geschichte... Was const ist wird vom Compiler als const behandelt. Wenn du mit const_cast Mist baust bist du selber schuld (das nennt man dann undefined behaviour). Nur weil man const verwendet bedeutet das noch lange nicht dass man const correct ist...

Zitat von »"kiba"«

Zitat von »"dot"«

Zitat von »"kiba"«

Glaube dafür könnte man const_cast gut benutzen...(aber ist es den auch für Pointer in Ordung?)

Warum willst du das const da wegcasten!? Der Benutzer gibt dir einen const A* und du machst dir einfach einen A* draus, kannst a dann also verändern obwohl der Benutzer denkt dass du es nicht kannst!?

Weil sonst eine Kompielerfehler kommt, den man kann ja nicht const A* zu A* convertieren.

Hää wtf?! Klar kommt da ein Kompilierfehler, denn es macht gar keinen Sinn!

Hat er doch schon richtig erkannt.