Hallo,
sicher kam das schonmal hier aber habe es nicht gefunden.
Müssen #define Berechnungen gecasted werden, wenn Zwischenergebnisse zb größer sind als 16 Bit? Auch für float die gleiche Frage: Müssen da dann kommastellen an die Zahlen? Also 500.0
oder ähnlich einen Fehler erzeugen zur Kompilierzeit, wenn mein Struct in diesem Fall die Größe des EEPROMS übersteigt? So wie geschrieben klappt es jedenfalls nicht. Der Fehler wird immer ausgelöst. Derzeit behelfe ich mir diese Angaben zur Laufzeit zu prüfen, was aber umständlich ist, da sie ja nicht dynamisch sind.
Meine Meinung zu #define: lass sie weg. Da passieren nur Fehler.
Ich frage mich wie ich ein Programm mit derzeit 13.000 Zeilen und 5 Modulen ohne sowas schreiben soll, wenn es wartbar bleiben soll? Natürlich ersetzt das nur aber ausgerechnet wird es trotzdem!
Nur nach welchen Regeln?
Habe kein assert etc. Läuft auf einem Cortex M0 Bare Metal Code geschrieben...
oder ähnlich einen Fehler erzeugen zur Kompilierzeit, wenn mein Struct
in diesem Fall die Größe des EEPROMS übersteigt?
Nein. Der Präprozessor heisst so, weil er im Prinzip als selbstständiges Programm dem Compiler voran läuft und keine intime Kenntnis vom dem hat, was erst der Compiler weiss. Und sizeof kennt erst der Compiler.
Müssen #define Berechnungen gecasted werden, wenn Zwischenergebnisse zb
größer sind als 16 Bit? Auch für float die gleiche Frage: Müssen da dann
kommastellen an die Zahlen? Also 500.0
Berechnungen finden im grössten Integer Typ statt. Es geht nur Integer und sonst nix. Casten gibt es im Präprozessor nicht.
Wenn das Ergebnis unsigned sein soll, kannst du U dranhängen.
Die binaries aller anderen Architekturen ausser X86 können zwar erzeugt, aber nicht ausgeführt werden. Wie auch. Der Server müsste die anderen Architekturen dafür ja alle emulieren können.
Nein. Der Präprozessor heisst so, weil er im Prinzip als selbstständiges
Programm dem Compiler voran läuft und keine intime Kenntnis vom dem hat,
was erst der Compiler weiss. Und sizeof kennt erst der Compiler.
Zumindest bei dem GCC weiss ich nicht, ob das so stimmt.
Folgendes Beipiel habe ich mal angehängt zum Gegenbeweis:
Übersetzen mit gcc x.c -O0 --save-temps erzeugt die angehängte *.s Datei (Assembler output)
in func1() (per define) wird die Division durch 10 durch eine Multiplikation und anschliessendes Shift ersetzt.
In func2() (per const Variable) wird der HW Divisionsbefehl benutzt. (Den will ich vermeiden, weil auf den meisten Prozessoren arschlangsam.)
Wenn ich mit -O2 übersetze, kommt bei func1() und func2() dasselbe heraus.
Das ist zumindest merkwürdig.
Irgendetwas macht der Prepro, was eigentlich Aufgabe des Compilers wäre.
Nein. Der Präprozessor heisst so, weil er im Prinzip als selbstständiges
Programm dem Compiler voran läuft und keine intime Kenntnis vom dem hat,
was erst der Compiler weiss. Und sizeof kennt erst der Compiler.
Zumindest bei dem GCC weiss ich nicht, ob das so stimmt.
Beim GCC ist der Präprozessor mit im Compiler eingebaut, aber dadurch darf sich dessen Verhalten natürlich nicht ändern.
In func2() (per const Variable) wird der HW Divisionsbefehl benutzt.
(Den will ich vermeiden, weil auf den meisten Prozessoren arschlangsam.)
Das hat aber nichts mit dem Präprozessor zu tun, sondern damit, dass eine const-Variable eben keine Konstante ist, sondern immer noch eine Variable, während die direkt hingeschriebene Zahl 10 eine echte Konstante ist, und durch die ersetzt ja der Präpozessor jedes Vorkommen von "Teilfaktor" (das eher "Divisor" heißen müsste).
Variable, während die direkt hingeschriebene Zahl 10 eine echte
Konstante ist, und durch die ersetzt ja der Präpozessor jedes Vorkommen
von "Teilfaktor" (das eher "Divisor" heißen müsste).
Eben nicht! Genau das passiert nicht. Schau Dir den Assemblercode noch einmal an. Da wird in func1() vorher etwas errechnet, die 10 taucht nicht auf.
Eben nicht! Genau das passiert nicht. Schau Dir den Assemblercode noch
einmal an. Da wird in func1() vorher etwas errechnet.
Bei mir wird da immer der identische Code erzeugt, mit -O1 und -O2.
Nur wenn das "const" bei tf weggelassen wird, dann wird func2 kompakter, weil nur ein idiv verwendet wird.
Die Optimierung sollte eigentlich nur bei -O2 angemacht werden, und nicht bei -O1 / -Os, weil sie in 99/100 Fällen nichts bringt und Platz braucht.
Interessanterweise liefert der MS cl den kompaktesten Code.
Das static_assert Macro gibt es in Windows seit ca. NT 4.x, da wird es so gemacht:
#define STATIC_ASSERT(expr) typedef char _assert_type[(expr)? 1 : -1]
Der Fehler wird aber nicht vom Präprozessor sondern vom Compiler generiert, der ein ungültiges Typedef sieht.
Das BUILD_BUG_ON Macro vom Beitrag weiter vorne funktioniert bei mir überhaupt nicht.
Weil ich dem Compiler verboten habe, zu optimieren. Vielleicht tut er es
trotzdem, kann ja sein.
Eine Compiler-Option zum Verbot des Optimierens wäre ungewöhnlich. Meist gibt es nur verschieden wählbare "zusätzliche" Optimierungsstufen, die mit mehr Aufwand Platz/Laufzeit weiter optimieren.
Die Speicherklassen in C werden ihren Namen selten gerecht: an auto ist nix automatisch, an static ist (meist) nichts statisch, volatile ist keineswegs unberechenbar und const ist nicht konstant (sondern readonly).
Noch nicht mal deine Präprozessor "Konstanten" sind Konstanten (sondern Literale).
Die Speicherklassen in C werden ihren Namen selten gerecht: an auto ist
nix automatisch,
Doch, natürlich. Der Speicher wird bei Verlassen des Blocks, in dem die Variable definiert ist, automnatisch wieder frei.
an static ist (meist) nichts statisch,
Außerhalb von Funktionen nicht, aber innerhalb schon. Außerhalb von Funktionen hat es eine andere Bedeutung zugewiesen bekommen.
volatile ist keineswegs unberechenbar
volatile heißt nicht unberechenbar, sondern flüchtig oder unbeständig, und genau darum geht es da. Der Wert muss jedesmal neu gelesen werden, weil nicht unbedingt das mehr drin steht, was man im Kontrollfluss vorher reingeschriebne hat.
und const ist nicht konstant (sondern readonly).
Zumindest da würde ich zustimmen.
Noch nicht mal deine Präprozessor "Konstanten" sind Konstanten (sondern
Literale).
Wie schon gesagt: Doch, sind sie. Der Begriff "integer literal" kommt im C-Standard im Gegensatz zu "integer constant" überhaupt nicht vor.
Die Speicherklassen in C werden ihren Namen selten gerecht: an auto ist
nix automatisch,
Doch, natürlich. Der Speicher wird bei Verlassen des Blocks, in dem die
Variable definiert ist, automnatisch wieder frei.
das gilt für alle (auch die globalen) Variablen in C. Ausser denen, die statisch sind. auto ist nicht "automatischer" als eine globale Variable.
an static ist (meist) nichts statisch,
Außerhalb von Funktionen nicht, aber innerhalb schon. Außerhalb von
Funktionen hat es eine andere Bedeutung zugewiesen bekommen.
volatile ist keineswegs unberechenbar
volatile heißt nicht unberechenbar, sondern flüchtig oder unbeständig,
und genau darum geht es da. Der Wert muss jedesmal neu gelesen werden,
weil nicht unbedingt das mehr drin steht, was man im Kontrollfluss
vorher reingeschriebne hat.
volatile heisst (in meinem Oxford dictionary) durchaus unberechenbar (von mir aus auch instabil oder leicht verdunstend. "flüchtig" fällt nur dem englischen Chemiker zuerst ein, dem von der Strasse nicht.
Noch nicht mal deine Präprozessor "Konstanten" sind Konstanten (sondern
Literale).
Wie schon gesagt: Doch, sind sie. Der Begriff "integer literal" kommt im
C-Standard im Gegensatz zu "integer constant" überhaupt nicht vor.
Wenn "3.141" eine Konstante ist, ist es längst nicht dasselbe wie "const double pi = 3.141". Da ist in der Begrifflichkeit schon was falsch. Von pi z.B. kann ich eine Adresse ermitteln, von 3.141 jedoch nicht - das kann also nicht dasselbe sein.
Doch, natürlich. Der Speicher wird bei Verlassen des Blocks, in dem die
Variable definiert ist, automnatisch wieder frei.
das gilt für alle (auch die globalen) Variablen in C. Ausser denen, die
statisch sind.
Globale Variablen sind immer statisch.
"static" ist (auf oberstem Niveau) ein im Nachhinein gesehen sehr unglücklich gewählter Name. Heute weiß man es besser, dass man hätte die Voreinstellung (ohne Schlüsselwort) so machen sollen, dass die Objekte (und Funktionen) dabei nur innerhalb der Übersetzungseinheit sichtbar sind, während man eine globale Sichtbarkeit mit einem extra Schlüsselwort ("extern" oder "global") explizit anfordert. Ist leider nicht so, also hat "static" auf oberstem Niveau eine andere Bedeutung als innerhalb von Funktionen.
volatile heisst (in meinem Oxford dictionary) durchaus unberechenbar
(von mir aus auch instabil oder leicht verdunstend.
Wobei ich diese Übersetzung durchaus auch zutreffend finde. Der Inhalt er Variable kann sich "unberechenbar", durch für an dieser Stelle im Programmfluss nicht erkennbare Einflüsse, verändern und ist daher als "instabil" anzusehen. Gegenmaßnahme, der Wert muss bei jedem Zugriff erneut von der Originaladresse gelesen und geschrieben werden (das Atomar zu gestalten ist wieder eine andere Baustelle). Der Inhalt darf nicht über mehrere Befehle hinweg z.B. in einem Register zwischengespeichert werden wie es bei einem "stabilen" Wert gemacht werden darf der sich nicht "unvorhersehbar" verändern kann.
Doch, natürlich. Der Speicher wird bei Verlassen des Blocks, in dem die
Variable definiert ist, automnatisch wieder frei.
das gilt für alle (auch die globalen) Variablen in C.
Globale Variablen stehen gar nicht in einem Block. Sie existieren über die gesamte Programmlaufzeit hinweg. Aus Sicht des Programms werden sie nie freigegeben.
Ausser denen, die statisch sind.
Bezüglich der Lebensdauer gibt es auf globaler Ebene keinerlei Unterschied zwischen static und nicht-static Variablen.
auto ist nicht "automatischer" als eine globale Variable.
Doch. Ich kann in einem Programm 100 mal eine Funktion aufrufen, und dann werden deren lokale Variablen 100 mal erzeugt und 100 mal wieder freigegeben. Bei rekursiven Funktionen gibt es für jede Aufrufebene eine eigene Instanz der Variablen.
Nach dem Rücksprung aus der Funktion ist die Variable jeweils nicht mehr existent und wird beim nächsten Aufruf neu erzeugt.
Wenn "3.141" eine Konstante ist, ist es längst nicht dasselbe wie "const
double pi = 3.141". Da ist in der Begrifflichkeit schon was falsch. Von
pi z.B. kann ich eine Adresse ermitteln, von 3.141 jedoch nicht - das
kann also nicht dasselbe sein.
Richtig. Deshalb habe ich weiter oben geschrieben, dass
Globale Variablen stehen gar nicht in einem Block. Sie existieren über
die gesamte Programmlaufzeit hinweg. Aus Sicht des Programms werden sie
nie freigegeben.
Komisch. Bei mir sind die globalen Variablen nach dem Programmende immer weg.
Joke aside - was ich meinte war: Variablen verschwinden, wenn ihr Scope verlassen wird. Globale Variablen sind auf dem äussersten Scope definiert (völlig wurscht, wie sie intern organisiert sind und dass sie nicht auf dem Stack liegen). Dieser Scope wird nur ein einziges Mal betreten. Wird dieser Scope verlassen (bei einem µC-Programm passiert das nie), sind sie weg (also genauso "automatisch" wie auto-Variablen).
Globale Variablen sind auf dem äussersten Scope definiert
(völlig wurscht, wie sie intern organisiert sind und dass
sie nicht auf dem Stack liegen).
Die /könnten/ doch genauso gut auf dem Stack liegen? Man könnte die ganze bss section sparen, das wäre doch für ein Mikro-RTOS durchaus vorteilhaft. Aber wie sähe die C-Syntax dafür aus?
Wird dieser Scope verlassen (bei einem µC-Programm passiert
das nie), sind sie weg
oh, das passiert sehr wohl. Man kann aus main() zurückkehren und landet dann im Startupcode. Wenn in main jetzt threads gestartet wurden und auf nicht mehr gültige Variablen oder Objekte aus main zugreifen wollen, dann gibt das lustige Effekte und man sucht Fehler erstmal ganz woanders.
Globale Variablen sind auf dem äussersten Scope definiert
(völlig wurscht, wie sie intern organisiert sind und dass
sie nicht auf dem Stack liegen).
Die könnten doch genauso gut auf dem Stack liegen? Man könnte die
ganze bss section sparen, das wäre doch für ein Mikro-RTOS durchaus
vorteilhaft. Aber wie sähe die C-Syntax dafür aus?
Das könnten sie - völlig ohne Änderung der Syntax. Der Compiler müsste sich eben eine Tabelle mit Stack-Offsets anlegen.
Es würde allerdings den Austausch von Daten zwischen Startup-Code und dem C-Programm erschweren.
"static" ist (auf oberstem Niveau) ein im Nachhinein gesehen sehr
unglücklich gewählter Name. Heute weiß man es besser, dass man hätte die
Voreinstellung (ohne Schlüsselwort) so machen sollen, dass die Objekte
(und Funktionen) dabei nur innerhalb der Übersetzungseinheit sichtbar
sind, während man eine globale Sichtbarkeit mit einem extra
Schlüsselwort ("extern" oder "global") explizit anfordert.
Ist leider
nicht so, also hat "static" auf oberstem Niveau eine andere Bedeutung
als innerhalb von Funktionen.
Hmm, na ja, ganz anders ja aber nun auch nicht.
1
int foobar =1;
2
static int foobar2 =2;
3
4
static void funcFoo() {}
5
void funcFoo2() {}
6
7
int main()
8
{
9
static int foobar3=3;
10
foobar = 0;
11
foobar2= 0;
12
foobar3= 0;
13
14
funcFoo();
15
funcFoo2();
16
17
return 0;
18
}
Da sagt der nm dann schon für Funktionen und Variablen, dass die groß- bzw. kleingeschrieben werden bei den Symbolen: (groß: global, klein: local)
1
0000000000601028 D foobar
2
0000000000601030 d foobar2
3
0000000000400520 t funcFoo
4
00000000004004c0 T funcFoo2
5
00000000004004d0 T main
6
000000000060102c d main.foobar3
Ansonsten aber stimm ich dir zu, es wär besser, per Default Variablen und Funktionen aus Linker-Sicht lokal zu halten - zumindest bei C/C++.
Globale Variablen stehen gar nicht in einem Block. Sie existieren über
die gesamte Programmlaufzeit hinweg. Aus Sicht des Programms werden sie
nie freigegeben.
Komisch. Bei mir sind die globalen Variablen nach dem Programmende immer
weg.
Ich schrieb ganz bewusst "aus Sicht des Programms". Nach dem Programmende gibt's keine Sicht des Programms mehr, weil es weg ist. Was dann mit dem Speicher passiert, interessiert das Programm nicht mehr: "Not my job". Und erzeugt werden sie bereits vor der Ausführung von main(). Also existieren diese Variablen aus Sicht des Programms für immer.
Bei automatischen Variablen ist das anders. Die werden innerhalb des Programms beliebig oft erzeugt und entsprechend natürlich auch wieder freigegeben, und das ganz automatisch.
Müssen #define Berechnungen gecasted werden, wenn Zwischenergebnisse zb
größer sind als 16 Bit? Auch für float die gleiche Frage: Müssen da dann
kommastellen an die Zahlen? Also 500.0
Berechnungen finden im grössten Integer Typ statt. Es geht nur Integer
und sonst nix. Casten gibt es im Präprozessor nicht.
Wenn das Ergebnis unsigned sein soll, kannst du U dranhängen.
Fast. Berechnungen im Präprozessor werden in intmax_t (vorzeichenbehaftet) bzw. uintmax_t (vorzeichenlos) ausgeführt.
Seit C23 ist aber (u)intmax_t nicht mehr notwendigerweise der größte Ganzzahltyp.
