static const

[Philipp S. (philipp09)]

Hallo,

ich habe eine Frage zur Deklaration eines Feldes. Was bedeutet es, wenn 
ich ein Feld innerhalb einer Funktion mit "static const" deklariere?

Bsp:

void foo(void)
{
   static const char var[4] = {0xFF,0xFF,0xFF,0xFF};
}



Trifft denn folgende Aussage zu, auch wenn ich das Ganze auf einem µC 
programmiere?

http://www.gamedev.net/topic/553167-static-const-vs-const-in-function-scope/

[Εrnst B. (ernst)]

Welche Aussage in dem verlinkten Thread? Dass der Computer piepst und 
dann Feuer fängt?

Was spricht dagegen, den Codeschnippsel einfach durch deinen Compiler 
mit deinen Optimierungseinstellungen zu jagen, und sich den 
generierten ASM-Code anzusehen?

Der Compiler hat da recht viele Freiheiten, was er wie optimieren darf. 
Welche er wählt, hängt von zu vielem drumherum ab, um da jetzt eine 
generelle Aussage treffen zu können.

[Oliver (Gast)]

Εrnst B✶ schrieb:
> Der Compiler hat da recht viele Freiheiten

Hat er nicht. Er sollte zunächts mal genau das tun, was der C-Standard 
für diesesn Fall definiert. Nur innerhalb dieser Grenzen hat er dann 
Freiheiten.

Also sollte man im C-Standard (oder in einen einigermassen brauchbaren 
C-Buch) einfach mal nachlesen.

Oliver

[Philipp S. (philipp09)]

Da hast du allerdings recht. Ich dachte nur es gibt darauf eine 
"Lehrbuchbeschreibung", die allerdings in den vom mir genutzten Büchern 
nicht auftaucht. Dann wer ich wohl nochmal meine ASM Kenntnisse bemühen.

Danke dir ;-)

[Εrnst B. (ernst)]

Oliver schrieb:
> Hat er nicht

Hat er schon.
z.B. kann er die Variable ganz weglassen, wird ja nirgends drauf 
zugegriffen. Er könnte sie aber z.B. auch mehrfach anlegen, damit jeder 
CPU-Core seine eigene lokale Kopie im Cache hat, usw.

> Also sollte man im C-Standard ...

Der C-Standard schreibt nur vor, wie sich das Compilat nachher zu 
Verhalten hat, nicht auf welchem Weg der Compiler zu diesem Ergebnis 
kommt.

[Oliver (Gast)]

Εrnst B✶ schrieb:
> Der C-Standard schreibt nur vor, wie sich das Compilat nachher zu
> Verhalten hat, nicht auf welchem Weg der Compiler zu diesem Ergebnis
> kommt.

Richtig. Nur war die Frage des TO nicht "was macht der Compiler aus 
static const" (das ist nur das Thema im verlinkten Thread), sondern "was 
bedeutet static const". Und das steht im C-Standard.

Oliver

[(prx) A. K. (prx)]

Philipp S. schrieb:

> Trifft denn folgende Aussage zu, auch wenn ich das Ganze auf einem µC
> programmiere?

Falls du "static const is redundant, const are static by default" 
meinst: Diese Aussage ist falsch.

[Stefan E. (sternst)]

Wieso ist hier eigentlich ständig die Rede von C und C-Standard? Seine 
Frage bezog sich auf einen anderen Thread, und in dem geht es ganz klar 
um C++. Und gerade bei "const" gibt es da erhebliche Unterschiede.

[(prx) A. K. (prx)]

Stefan Ernst schrieb:

> Wieso ist hier eigentlich ständig die Rede von C und C-Standard? Seine
> Frage bezog sich auf einen anderen Thread, und in dem geht es ganz klar
> um C++.

Wozu man da erst einmal reinsehen muss. Hier stehts jedenfalls nicht. 
Bei der Deklaration
  void foo(void)
springt der Gedanke an C++ auch nicht sofort ins Auge.

Abgesehen davon stimmt die Aussage bei C++ ebensowenig wie bei C.

[Εrnst B. (ernst)]

Stefan Ernst schrieb:
> Frage bezog sich auf einen anderen Thread,

Um den anderen Thread zu zitieren:

> Also not quite right. The results of modifying a variable originally
> declared as const are undefined. The computer could print 27; it could
> print 42; it could print -8.2; it could beep and then catch fire.

Dazu die Frage:

Philipp S. schrieb:
> Trifft denn folgende Aussage zu, auch wenn ich das Ganze auf einem µC
> programmiere?

Also die Antwort:

Nein, dein µC wird nicht Piepsen, dafür fehlt der Lautsprecher.


Alle Klarheiten beseitigt?

[Philipp S. (philipp09)]

Ok, vergessen wir doch das mit dem Link, den ich zur Verwirrung aller 
(inklusiver mir selbst) in meinem ersten Beitrag gepostet hab. Vielmehr 
interessiert doch die Frage, worin der Unterschied zu folgenden 
Deklarationen liegt:

(Alle seien innerhalb einer Funktion deklariert, also nicht global)

1.

static char var[4] = {0xFF,0xFF,0xFF,0xFF};

2.

const char var[4] = {0xFF,0xFF,0xFF,0xFF};

3.

static const char var[4] = {0xFF,0xFF,0xFF,0xFF};

Fall 1 und 2 sind wohl allen bekannt, aber wie sieht es mit dem dritten 
aus?

[Εrnst B. (ernst)]

Fall 1: var liegt am Stack
Fall 2+3: var liegt im Data.
Fall 1+3: Compiler verbietet Änderungen an Var.

Alles unter der Prämisse, das der Compiler das Array nicht wegoptimieren 
kann, z.B. weil mittels "&var" dessen Adresse verwendet wird.

[Klaus W. (mfgkw)]

Was soll damit sein?
Wegen static liegt das Feld statisch im Speicher, wird also nicht bei 
jedem Funktionsaufruf auf Stack angelegt.
Wegen const darfst du die Werte nicht ändern.

Was der Compiler daraus macht, ist dann seine Sache (z.B. könnte er
Zugriffe auf die Elemente durch Konstanten im Code ersetzen, muß es aber 
nicht).

[(prx) A. K. (prx)]

Εrnst B✶ schrieb:

> Fall 1: var liegt am Stack
> Fall 2+3: var liegt im Data.
> Fall 1+3: Compiler verbietet Änderungen an Var.

Fall 1+3: Static ist statisch, d.h. die Daten liegen im Datensegment mit 
fester Adresse. Nur ist der Name ausserhalb der Funktion nicht bekannt.

Fall 2: Liegt im Stack.

[Εrnst B. (ernst)]

Εrnst B✶ schrieb:
> Fall 1: var liegt am Stack
> Fall 2+3: var liegt im Data.
> Fall 1+3: Compiler verbietet Änderungen an Var.

Muss natürlich
Fall 2: var liegt am Stack (const)
Fall 1+3: var liegt im Data. (static + const static)
Fall 2+3: Compiler verbietet Änderungen an Var. (const + const static)

heißen.

Nur falls das jemandem noch nicht aufgefallen ist...

[Philipp S. (philipp09)]

Jungs, vielen Dank ... jetzt hab ich es verstanden :-)

[Yalu X. (yalu) (Moderator)]

Philipp S. schrieb:
> 2.
> const char var[4] = {0xFF,0xFF,0xFF,0xFF};

Εrnst B✶ schrieb:
> Fall 2: var liegt am Stack (const)

GCC 4.2 hat die Variable noch ins Data gelegt, ab 4.3 kam sie dann auf
den Stack. Die beiden Varianten unterscheiden sich wegen dem const nicht
funktional, sondern nur im Speicherabbild. Trotzdem war wohl 4.2 nicht
ganz standardkonform, da lokale Variablen, die nicht mit static dekla-
riert werden, automatic storage duration haben müssen.

[Johann L. (gjlayde)]

Yalu X. schrieb:

> Trotzdem war wohl 4.2 nicht
> ganz standardkonform, da lokale Variablen, die nicht mit static dekla-
> riert werden, automatic storage duration haben müssen.

Bitte nicht "static" und "static storage" verwechseln.

[Εrnst B. (ernst)]

Yalu X. schrieb:
> GCC 4.2 hat die Variable noch ins Data gelegt

Ich hatte es mit dem 4.5er getestet, bevor ich gepostet hatte ;)

Interressant wirds mit Keil,SDCC &co, also mehr auf Harvard angelegte 
Compiler, die "const"-Variablen ggfs. direkt im Flash unterbringen.