Ich lerne momentan C++ und im Buch wird eher auf Perfomance und Stil geschaut.

Nun, wieso wird die Größe eines C-Arrays extra mit einem const int bestimmt?!

//BEISPIEL A
const int ANZAHL = 20;
int carray[ANZAHL];

Wäre es nicht besser so:

//BEISPIEL B
int carray[20];

Oder macht der Compiler nichts anderes als BEISPIEL B zu ändern und die 20 als const int zudeklarieren?

Mir schwirrt die Frage die ganze Zeit im Kopf herum, bräuchte endlich eine Antwort

Gruß dipling

bb

na dann ist ja gut

Danke!

Man sollte noch dazu sagen, dass in C++ solche konstanten Integrale wegoptimiert werden müssen [...], da Arraygrenzen [...] Compiletimekonstanten sein müssen.

Das eine impliziert ja nicht das andere... Wenn der Wert schon zur Compilezeit bekannt ist, ist es gültiges C++, egal ob zur Laufzeit trotzdem noch eine Variable erstellt wird oder immer gleich das Literal eingesetzt wird.

(Natürlich wird es im Normalfall wegoptimiert, nicht dass du mich missverstehst... ;))

Das eine impliziert ja nicht das andere... Wenn der Wert schon zur Compilezeit bekannt ist, ist es gültiges C++, egal ob zur Laufzeit trotzdem noch eine Variable erstellt wird oder immer gleich das Literal eingesetzt wird.

(Natürlich wird es im Normalfall wegoptimiert, nicht dass du mich missverstehst... ;))

Ich wollte es auch nur herausheben, da sich unskilleds Post etwas so anhörte als dürfte der Compiler es im Debugmodus auch lassen.

Um es ganz vollständig zu machen: Eine solche Konstante wird _spätestens_ dann zur "Variablen", wenn man die Adresse der Variablen anfordert (oder u.U. auch, wenn man eine Referenz daran bindet). Allerdings führt das modifizieren einer solchen trotzdem zu undefined behaviour.

(Dass Du das weißt, Nexus, ist mir nebenbei auch klar :))

EDIT: "spätestens" hinzugefügt, da ich nicht weiss ob der Compiler nicht auch zusätzlich Speicher für die Konstante anlegen darf, obwohl jedes Vorkommen ersetzt wird _und_ niemand die Adresse haben will.

Nexus schrieb:

Das eine impliziert ja nicht das andere... Wenn der Wert schon zur Compilezeit bekannt ist, ist es gültiges C++, egal ob zur Laufzeit trotzdem noch eine Variable erstellt wird oder immer gleich das Literal eingesetzt wird.

(Natürlich wird es im Normalfall wegoptimiert, nicht dass du mich missverstehst... ;))

Ich wollte es auch nur herausheben, da sich unskilleds Post etwas so anhörte als dürfte der Compiler es im Debugmodus auch lassen.

Um es ganz vollständig zu machen: Eine solche Konstante wird _spätestens_ dann zur "Variablen", wenn man die Adresse der Variablen anfordert (oder u.U. auch, wenn man eine Referenz daran bindet). Allerdings führt das modifizieren einer solchen trotzdem zu undefined behaviour.

Also bei mir kompiliert auch:

int main() {
	const int count = 20;
	const int* foo = &count;
	double array[count];
}

@Nexus: Klugscheisserisch kam nichts rüber, ich (in der Tat denke ich, wir alle) sollte nur öfter mal genau klarstellen was ich eigentlich klarstellen möchte

@Nexus: Klugscheisserisch kam nichts rüber, ich (in der Tat denke ich, wir alle) sollte nur öfter mal genau klarstellen was ich eigentlich klarstellen möchte

Wir sollen öfter klarstellen, was du klarstellen möchtest?

Sorry, aber der Satz hat Klassiker Potential und ist auf eine Art rekursiv. Einfach toll.

Ja, weil Du hier foo die Adresse von count zuweist und der Compiler das count in den Arrayklammern durch 20 ersetzt

Mir ist egal, wie der Compiler das macht. Wichtig ist: count ist eine Compilezeitkonstante und kann damit für die Arraydeklaration benutzt werden.

Ob die Variable dann auch gleich wegoptimiert wird oder nicht, hat damit eigentlich nichts zu tun.

Mir ist egal, wie der Compiler das macht. Wichtig ist: count ist eine Compilezeitkonstante und kann damit für die Arraydeklaration benutzt werden.

Ja, widerspricht ja nun auch wieder nicht den vorangegangenen Aussagen. Auch nicht wenn eine Adresse genommen wird.

Aber ich denke, in diesem Thread ist soweit alles klargestellt *duck*.

Ich/wir sollte(n) klarstellen, was ich/wir klarstellen möchte(n) (nicht zutreffendes bitte streichen), besser? :p

Mir persönlich gefiel der alte besser, aber OK.

Ich wollte es auch nur herausheben, da sich unskilleds Post etwas so anhörte als dürfte der Compiler es im Debugmodus auch lassen.

Das ist imho auch der Fall.

int main()
{
	const int x = 23;
	int arr[x] = {0};
}

breakpoint auf int arr[x] und du siehst, dass x als Variable existiert. Nur das wollte ich damit sagen.

int main()
{
008413A0  push        ebp  
008413A1  mov         ebp,esp 
008413A3  sub         esp,130h 
008413A9  push        ebx  
008413AA  push        esi  
008413AB  push        edi  
008413AC  lea         edi,[ebp-130h] 
008413B2  mov         ecx,4Ch 
008413B7  mov         eax,0CCCCCCCCh 
008413BC  rep stos    dword ptr es:[edi] 
	const int x = 23;
008413BE  mov         dword ptr [x],17h ; <--- hier?! ^^
	int arr[x] = {0};
008413C5  mov         dword ptr [arr],0 
008413CC  push        58h  
008413CE  push        0    
008413D0  lea         eax,[ebp-68h] 
008413D3  push        eax  
008413D4  call        @ILT+115(_memset) (841078h) 
008413D9  add         esp,0Ch 
}

Auch das sieht für mich so aus, als ob der Compiler im Debug-Mode das x nicht einfach nur durch 23 "ersetzt".

bb

Auch das sieht für mich so aus, als ob der Compiler im Debug-Mode das x nicht einfach nur durch 23 "ersetzt".

Das ist einfach nur die Initialisierung von x.
Mit Optimierung hat das alles sowieso nichts zu tun:
x ist
- integral
- konstant
- wird durch konstanten Ausdruck (ein Literal in diesem Fall) initialisiert.
Damit ist jeder folgende Ausdruck 'x' ebenfalls ein konstanter Ausdruck.
int arr[x]
Die Arraydimensionen in einer Arraydefinition müssen durch einen konstanten Ausdruck angegeben werden. Diese Dimensionen sind Teil des Arraytyps - damit ist jede Form von Berechnung, die erst während das Ablaufs des Programms stattfindet, in dieser Hinsicht ausgeschlossen. Weil x ein konstanter Ausdruck ist, ist diese Definition zulässig.