ZFX + Developia

Schönen Nachmittag liebe zfx'ler

Ich habe mir jetzt Zwecks Komfort und Übersicht meine eigenen Basistypen definiert.
Dabei hab ich mir die stdint.h und stdbool.h bei der Gelegenheit genauer angeschaut.

Was mich erstaunt:
In der stdint.h sind die Typen (hier bei mir) per typedef "umgemünzt". So z. B. auch der size_t In der stdbool.h sind sie jedoch per #define Makro implementiert Wenn ich das ganze per typedef umsetze, kriege ich ja vom Compiler so nette Meldungen wie "size_t aka unsigned long long".
Relevanter scheint mir jedoch die Typenprüfung - und die erhalte ich ja ohnehin in beiden Fällen. Denn sobald der Präprozesser drüber war, steht ja bei einem Makro der eigentliche "Ersatztext" da. Und dieser kann dann wiederum vom Compiler entsprechend überprüft werden.

Aber vielleicht gibts ja einen schlauen "Leitgedanken" - wann #define, wann typedef und in welchen Fällen das Eine dem Anderen vorzuziehen ist?

Ausserdem interessant:
In stdbool.h des gcc compilers sind die Makros true und false mit einem entsprechenden cast implementiert In der Header, die ich beim Clang Compiler finde, wird darauf verzichtet: Die Prämisse, den Code nicht durch unnötigen "clutter" aufzublähen, finde ich ja eigentlich sehr einleuchtend.
Ist denn der cast zu _Bool (oder bool ab c23) wirklich nötig?

Gruss starcow

https://en.cppreference.com/w/c/language/arithmetic_types#Boolean_type hat geschrieben:_Bool (also accessible as the macro bool)(until C23) / bool (since C23)

Bis C23 hatte der Standard bool als Makro definiert; ab C23 nicht mehr.

Warum konkret das ein Makro war, kann ich dir nicht sagen. Ich schätze, dass bool mit wesentlich mehr Legacy-Code kollidiert als die Standard-Integer-Typen – mein Arbeitgeber hat z. B. drei verschiedene, selbst geschriebene Implementierungen von bool. Dafür war ein Makro vielleicht besser geeignet, weil man mit #ifdef bool auf kollidierende Implementierungen testen kann, während das mit typedef nicht geht.

Ist nur geraten, aber was es auch war, es ist mit C23 weg.

Ok, interessante These! Danke!
Ich denke ich werde in diesem Fall für die Basistypen weiterhin konsequent auf typedef setzen (u8, i8, u16, i16, u32, i32, u64, i64).