# Unterschied von static const zu #define



## LukeS (19. Februar 2011)

Hallo zusammen

Ich habe folgende Frage:
Was ist der genaue Unterschied zwischen


```
static const int i = 5;
```
und


```
#define i 5
```

Im 1. Fall meine ich eine globale Konstante. Weder eine statische lokale Funktionsvariable noch einen statische Klassen Member.

Mir ist klar, dass im 2. Fall der Präprozessor vor dem Kompilieren alle i im Quelltext durch 5 ersetzt. Doch dann steht da einfach ein Literal im Code und der Compiler muss ja diese Zahl auch irgendwo im Speicher platzieren.

Mich interessiert dies vor Allem, für Code von Embedded Systemen, die kein Betriebsystem mit Loader haben, sondern das Programm in ein ROM/Flasch gebrannt haben.

Werden Zahlen, die als Literale im Quelltext vorkommen an einer Anderen Stelle im Speicher (Programmspeicher) als const Variablen (Datenspeicher) abgelegt?

Mich interessiert vor Allem, ob #define wirklich effizienter ist als static const. Eigentlich ist ja static const sicherer: Typen-Sicher, lokal beschränkt...

Aber in vielen Quelltexten (besonders C) wird #define bevorzugt verwendet.


Gruss Lukas


----------



## isaias_b (19. Februar 2011)

hiho lukas,

wenn der präprozessor die #defines im quellcode findet ersetzt er einfach den text durch anderen text in deinem fall die zahlen,
daraus folgen spezielle assembler statements mit den passenden zahlen beim compilieren,
bei der 2ten variante werden wirklich variablen angelegt auf die zugegriffen werden muss,
inwiefern der code optimizer bei einem embedded programm zusammen mit dem nicht vorhanden betriebssystem diese anlegt kann ich dir leider im detail auch nicht sagen.
aber es macht einen unterschied ob der assemblercode
mov a, 5
ist mit der zahl 5 wie in deinem beispiel
oder ob er erst an die stelle des symbols im speicher springen muss & den dort abgelegten ermitteln, diesen dann in den akku holt und dann damit weiter arbeiten kann.

ich weiß ja nicht ob du c oder c++ präferierst oder nutzen möchtest wenn du sagst du willst einen semantisch leicht nachvollziehbaren OOP ansatz mit deinem system fahren dann solltest du in jedem fall dich von den altlasten der C zeiten entledigen und über diese performance einbuße hinweg sehen.
schlimm wirds zwar eh erst mit makros^^
wenn du allerdings dies in kauf nimmst dann hätts du ein konsistentes codebild.

bla bla bla
das wars von mir
greez isaias


----------



## sheel (19. Februar 2011)

Hi

...wobei static const int auch nicht unbedingt die Performance verschlechtern muss. Eventuell wirds vom Compiler wegoptimiert, kommt dann aufs Gleiche raus wie #define.
Dann hat man eben nur eine andere Schreibweise.

Persönlich würde ich die static-const-Variante verwenden; nicht um kein C zu verwenden sondern um den Code leichter in andere Sprachen portierbar zu machen.
zB Java kennt nun mal kein #define, und in C# kann man einem #define keinen Wert geben. Es existiert einfach nur, man kann nur überprüfen ob es definiert wurde.

Gruß

PS @ isaias_b: Bitte beachte die Netiquette, P. 15. Danke.


----------



## isaias_b (19. Februar 2011)

@LukeS

Mir ist noch ein Grund für die Variante

```
static const int i = 5;
```
eingefallen. Typsicherheit hast du ja schon selber angesprochen, aber debugging wär vielleicht ebenfalls ein Punkt der nochmal in Betracht gezogen werden sollte.
In punkto Effizienz möchte ich meine Aussage vielleicht auch dahingehend anpassen, dass es stark vom Compiler abhängt was letzendlich aus den Symbol Konstanten bei der Übersetzung geschieht.

@ sheel Ich entschuldige mich für diesen Verstoß, ich habe die Netiquette gelesen und bemüh mich in Zukunft gegen meinen Trott zu wehren, Danke für den Hinweis


----------



## napstermania (21. Februar 2011)

Defines waren früher vielleicht mal eine schöne elegante Sache und Makros und sind auch immernoch für bestimmte Bereiche durchaus Sinnvoll und vertretbar. Aber wenn es darum geht einfach eine Varialbe mit einem Define zu setzen dann erfüllt das nicht seinen Sinn und Zweck.

Es mag in einem kleinen One-Man Projekt, welcher den Überblick über alles hat vielleicht noch nicht so sein, aber der Punkt ist der, das in umfangreichen, historisch gewachsenen Projekten so ein Define richtig dumme Fehler verursachen kann welche auch vom Kompiler nicht als solche erkannt werden. Bei einem solchen Projekt, welches mehrere 100 oder gar 1000k Zeilen Sourcecode enthält sind defines "meistens" schlecht.
Das konkrete Beispiel, als es mir bei der Fehlersuche so erging, ist mir leider entfallen, hängen geblieben ist nur, Defines sind mit vorsicht zu genießen.

Grüße


----------

