In der Welt der Programmierung spielt die Überprüfung, ob ein Ausdruck konstant ist, eine entscheidende Rolle, insbesondere wenn es darum geht, die Effizienz und Sicherheit von Code zu erhöhen. In der Programmiersprache C, die über Jahrzehnte vielseitig eingesetzt wird, ist die Fähigkeit, während der Kompilierung festzustellen, ob eine Expression konstant ist, nicht nur nützlich, sondern manchmal unverzichtbar. Konstanten ermöglichen der Compileroptimierung, Fehler frühzeitig zu erkennen und bedingen häufig eine klare und wartbare Codebasis. Doch wie lässt sich in C zuverlässig feststellen, ob ein Ausdruck konstant ist? Die Antwort ist komplex und hängt stark vom verwendeten C-Standard sowie den unterstützten Compiler-Erweiterungen ab. Zunächst lohnt es sich, den Begriff der Konstantheit in C zu präzisieren.
Ein konstanter Ausdruck ist ein Wert, dessen Größe und Inhalt zur Kompilierzeit vollends bestimmt ist. Das bedeutet, dass der Compiler die Rechenoperationen bereits vor der Ausführung berechnen und das Ergebnis festsetzen kann. Beispielsweise ist eine einfache Zahl wie 42 oder ein Ausdruck wie 6 * 7 in der Regel konstant, wohingegen eine Laufzeitvariable oder eine Operation mit Seiteneffekten dies nicht ist. Ein direkter Weg, diesen Anspruch zu erfüllen, ergibt sich mit dem neu eingeführten C23 Standard, der zahlreiche moderne Features mit sich bringt. Besonders hervorzuheben ist dort die Möglichkeit, für Compound Literals eine Speicherklasse namens "constexpr" zu verwenden.
Diese garantiert, dass der zugewiesene Wert tatsächlich ein konstanter Ausdruck sein muss. Mit Hilfe des Operators typeof, der ebenfalls in C23 standardisiert wurde, lässt sich dabei der Typ des Originalausdrucks beibehalten. Hieraus ergibt sich eine elegante Makrolösung, die zum Beispiel folgendermaßen aussehen kann: Ein Makro, das ein Argument x annimmt und extern (constexpr typeof(x)){x} zurückgibt. Der Vorteil dieser Methode besteht klar darin, dass der Compiler die Konstantheit garantiert und der Typ vom Compiler automatisch korrekt behandelt wird. Nachteilig ist jedoch, dass diese Funktionalität bisher nur von wenigen Compilern unterstützt wird.
Während GCC seit Version 14.2 bereits kompatibel ist, hinkt Clang aktuell noch hinterher. Des Weiteren ist der C23 Standard zum Zeitpunkt dieses Schreibens noch nicht flächendeckend verbreitet, wodurch diese Methode noch nicht uneingeschränkt genutzt werden kann. Wer auf GNU-Erweiterungen zurückgreifen darf, hat mit der Compiler-internen Funktion __builtin_constant_p eine weitere potente Möglichkeit. Dieser _builtin_ gibt einen booleschen Wert zurück, der angibt, ob der übergebene Ausdruck eine Konstante ist oder nicht.
Mit __builtin_choose_expr lässt sich diese Information dann in einem Makro nutzen, um bei konstanten Ausdrücken den Wert zurückzugeben, ansonsten aber einen gezielten Kompilierfehler auszulösen. Dafür kann eine Dummy-Funktion mit dem Attribut __attribute__((error("not constant"))) versehen werden, die unmittelbar zum Abbruch führt, falls der Ausdruck nicht konstant ist. Das Besondere an __builtin_choose_expr ist, dass sie nicht den Regeln der Typ-Promotion unterliegt, so dass der Typ des Originalausdrucks erhalten bleibt. So entsteht eine sehr elegante Lösung, die aber durch die Abhängigkeit von GNU-spezifischen Erweiterungen nicht universell einsetzbar ist. Eine weitere interessante Herangehensweise nutzt die _Static_assert-Funktionalität, die seit C11 offiziell unterstützt wird.
Mithilfe von sizeof und anonymen Strukturen lässt sich so ein Trick anwenden, der eine Kompilierzeitüberprüfung ermöglicht. Das Makro verknüpft die Addition des Arguments mit einer Größe, die von einer Struktur abhängig ist, in der eine statische Assertion geprüft wird. Die intensive Nutzung von sizeof sorgt dabei dafür, dass zur Laufzeit keine Auswirkung auf den Code entsteht. Die statische Assertion überprüft, ob der Ausdruck gültig ist und zur Kompilierzeit aufgelöst werden kann. Ein Nachteil dieser Methode ist, dass sich der Typ des Ausdrucks durch die Addition mit 0 unter Umständen ändert, weil Integer-Promotionen wirken, was die weitere Verwendung erschweren kann.
Außerdem kann es bei Fließkommazahlen durchaus zu Warnungen kommen, da formell nur Integer-Konstanten von _Static_assert erwartet werden. Eine nahe verwandte Methode kommt mit der Kombination aus sizeof und einem Compound-Literal vom Array-Typicaus. Da Compound Literale keine variable Länge unterstützen und Arrays mit Nullgröße in Standard-C verboten sind, kann hier eine Kompilierzeitüberprüfung etabliert werden, die auf der Größe eines Arrays basiert. Durch eine geschickte Konstruktion wird der Ausdruck also indirekt zur Kompilierzeit geprüft, da die Größe eine konstante Zahl sein muss. Diese Lösung ist damit kompatibel mit C99, benötigt also keine modernere Version und kann insbesondere für integerbasierte Konstanten gut eingesetzt werden.
Für Fließkommazahlen gelten jedoch ähnliche Einschränkungen wie bei der _Static_assert-Methode. Darüber hinaus kann auch hier durch den zugrunde liegenden Aufbau des Ausdrucks der Typ sich verändern. Eine weniger gängige, aber auch historisch interessante Variante beruht auf der Verwendung von enum-Konstanten. Da enums in C per Definition nur Ganzzahl-Konstanten zulassen, ist die Zuweisung eines Ausdrucks in einem enum-Feld eine sichere Kompilierzeitkonstante. Allerdings besteht hier das Problem, dass der enum-Name im globalen oder zumindest Funktionskontext „leaked“ und somit nicht mehrfach in einem Programm vorkommen darf.
Ein Workaround besteht darin, die eigentliche enum-Definition in einem Funktionsparameter zu verstecken, um so dem „Leaking“ entgegenzuwirken. Dennoch sind hierbei unangenehme Compiler-Warnungen zu erwarten und die Lösung unterstützt keine Fließkommazahlen. Sie ist jedoch kompatibel bis zurück zu C89, was für einige Legacy-Anwendungen noch relevant sein kann. Ein zentrales Problem bei vielen der vorgestellten Makros, die mit (x) + 0*sizeof(..
.) arbeiten, ist die Typänderung des Resultats durch additive Operationen. Eine elegantere Alternative ist es, den sizeof-Ausdruck in einem separaten Ausdruck mit dem Kommaoperator zu verwenden: Zuerst das sizeof, dessen Wert dann ignoriert wird, und danach der Rückgabewert des ursprünglichen Ausdrucks x. Das Ergebnis ist der Originalwert von x, während die Kompilierzeitüberprüfung im voraus geschieht. Allerdings meldet der Compiler hier häufig Warnungen, dass der linke Ausdruck des Kommaoperators ohne Effekt sei.
Eine einfache Abhilfe besteht darin, den sizeof-Ausdruck in einen void-Cast zu verpacken, wodurch diese Warnungen unterdrückt werden können. So entsteht eine fast perfekte Lösung bezüglich Typerhaltung und Kompilierzeitprüfung, die zudem in vielen Compilerumgebungen funktioniert. Es lohnt sich zudem, die Eigenheiten der einzelnen Compiler zu beachten. Beispielsweise zeigte sich bei einem frühen Versuch mit GCC, dass ein negativ großer Array-Typ als Fehler eigentlich erkannt werden sollte, der Compiler darauf aber nur mit einer Warnung reagierte. GCC zeigte hier eine gewisse Toleranz, was die Fehlererkennung unterlief.
Demgegenüber reagiert Clang erwartungsgemäß strikt. Deshalb ist der Einsatz einer Dummy-Funktion mit error-Attribut in Kombination mit __builtin_constant_p oft robuster als negative Array-Größen als Fehlerauslöser. In der Praxis stellt die Auswahl der richtigen Methode also immer einen Kompromiss dar. Wer maximale Portabilität wünscht, wird vielleicht bei der Enum-Variante stranden, obwohl sie eingeschränkte Funktionalität und nervige Warnungen mit sich bringt. Für moderne Umgebungen mit GCC oder Clang empfiehlt sich eher die __builtin_constant_p-Lösung, sofern GNU-Erweiterungen toleriert werden.
C23-Anwender können die neuen Features wie constexpr zur eleganten Lösung nutzen, müssen aber die Limitierungen in der Compilerunterstützung beachten. Für Projekte, die C11 unterstützen, bietet sich die _Static_assert-Technik als solide Variante an, auch wenn sie mit kleinen Einschränkungen leben muss. Abschließend bleibt festzuhalten: Die Kompilierzeitprüfung von Konstanten in C ist ein fast schon magisches Pflaster, das viele Entwickler begeistert, aber auch komplexe Überlegungen und Workarounds erfordert. Die Wahl der Methode muss sich stets an den spezifischen Anforderungen des Projekts und der verfügbaren Compilerumgebung orientieren. Die ständige Weiterentwicklung von C und seiner Compiler verspricht hier in Zukunft noch elegantere und sicherere Lösungen.
Bis dahin bleibt es spannend, die vorgestellten Techniken intelligent zu nutzen, um Code robuster, übersichtlicher und kompilerfreundlicher zu gestalten.
