Also die Vorteile von const zu define sind mir schon klar, blos eben dieser kleine Teil nicht...

Effektiv C++ schrieb:

Darüber hinaus kann im Fall einer Fließkommakonstante die Verwendung der Konstante zu kürzerem Code führen als der Einsatz von #define. Das liegt daran, dass die blinde Ersetzung von ASPECT_RADIO durch 1.653 durch den Präprozessor zu mehreren Kopien von 1.653 im Objektcode führen kann, währen der Einsatz von der Konstanten AspectRadio( das ist die const Variante ) niemals mehr als eine Kopie erzeugen sollte.

Versteh ich leider nicht

Schonmal danke für eure Hilfe

Lg freeG

Zum dem Teil mit dem kürzeren Code fällt mir nur diese Möglichkeit ein. Ist aber nur eine Vermutung!
Ohne Optimierung wird das durch den PP ersetzte Literal 1.653 jedes mal neu in das compilierte Programm geschrieben.

An einer mit "const" definierten Konstanten ändert der Präprozessor nichts, d.h. der Compiler erkennt, dass das immer der selbe Wert ist, und wird ihn nur einmal einkompilieren und dann mit Referenzen auf diese Stelle im Datensegment arbeiten.

allerdings:

niemals mehr als eine Kopie erzeugen sollte

Der Ausschnitt lässt so ziemlich alles offen, wie es auch der Standard tut.

Wenn man auf Geschwindigkeit optimiert (was eigentlich immer der Fall ist), dann wird das sehr wahrscheinlich auf das gleiche rauskommen.

Falls vielleicht auch jemand das Buch gelesen hat und sich an die Stelle erinnert oder es 100%ig weiß kann er es natürlich gern noch posten, wobei ich aber doch schon von ausgeh dass die Vermutung von Gast und drakon so richtig ist.

Also danke an euch beide

Lg freeG

Nur ist überhaupt nicht definiert, was der Compiler alles macht und somit ist das nur reine Spekulation, dass er da kürzeren Code erzeugt.

Sagen was passiert kann man nur definitiv für einen Compiler + die Einstellungen dafür.

Dass das jeder Compiler anderst handhabt find ich persönlich jetzt nicht mal so wichtig, hauptsache ich weiß dass man const ganz klar #define vorziehen soll und die Gründe dafür

Also nochmals Danke für die Hilfe mit meinem kleinen Verständnisproblem.

Lg freeG

Falls vielleicht auch jemand das Buch gelesen hat und sich an die Stelle erinnert oder es 100%ig weiß kann er es natürlich gern noch posten, wobei ich aber doch schon von ausgeh dass die Vermutung von Gast und drakon so richtig ist.

Weiss nicht, ob es wirklich richtig ist. Mich irritiert dabei, dass er von "Im Fall einer Fliesskommazahl" spricht. Und das ist nicht mal ein Übersetzungsfehler, ich habe hier die englische Version. Er erwähnt es in der englischen Version sogar fast noch expliziter:

Effective C++ Third Edition, Item 2, Page 13 schrieb:

In addition, in the case of a floating point constant (such as in this example), use of the constant may yield smaller code than using a #define. That's because the preprocessor's blind substitution of the macro name ASPECT_RATIO with 1.653 could result in multiple copies of 1.653 in your object code, while the use of the constant AspectRatio should never result in more than one copy.

Das was drakon und gast0815 angesprochen haben würde auch für ein Integer- oder String-Literal zutreffen. Ich verstehe nicht, wieso er hier so explizit die Fliesskommazahl erwähnt.

Grüssli

Allerdings habe ich jetzt auch gar nicht mehr daran gedacht.

Vielleicht weiß ja doch noch irgend jemand anderes was genau da gemeint ist.

Lg freeG

Und auf 32 Bit Systemen sind zudem Verweise (=Pointer) auf andere Codestellen kürzer als Fließkommawerte, während Integerkonstanten die gleiche Größe wie der Verweis haben.

Es kann so oder so ausgehen, kommt auf den Compiler an. Wäre auch denkbar dass Fliesskomma-Literals (#define) zu schnellerem Code führen als Fliesskomma-Konstanten (static const).