C++26 Contracts bringen Bedingungen direkt in die Funktionssignatur
C++26 Contracts: Introduction to Preconditions and Postconditions
C++26 führt Contracts ein, mit denen sich Vor- und Nachbedingungen direkt in der Funktionsdeklaration ausdrücken lassen. Statt assert im Funktionskörper zu verstecken, macht pre(index < values.size()) die Anforderung für jeden API-Leser sichtbar. post(result: ...) prüft Rückgabewerte über alle normalen Ausstiegspfade hinweg, contract_assert gilt innerhalb des Codes. Vier Auswertungssemantiken – ignore, observe, enforce, quick-enforce – steuern das Laufzeitverhalten. Derzeit unterstützt nur GCC 16 das Feature, das nicht zur Eingabevalidierung gedacht ist.
Wichtig ist, dass dieser Aspekt von Contracts der Grund dafür ist, dass Contract Assertions nicht zur Fehlerbehandlung und Eingabevalidierung verwendet werden dürfen: Wenn eine Funktion vertragliche Anforderungen hat, bestimmte Ereignisse als Fehler zu melden, muss diese Behandlung mit standardmäßigen C++-Kontrollanweisungen erfolgen, die nicht optional sind, niemals mit Contract Assertions.
- cogman10
Ich mag es nicht.
Ich bin voll dafür, einen Vertrag abzuschließen, wenn er einen Laufzeitfehler in einen Compile-Zeit-Fehler verwandeln kann. Allerdings sieht es so aus, als würde dies nur mehr Laufzeitfehler erzeugen. An diesem Punkt scheinen diese nicht besser zu sein als `assert`, außer dass sie versprechen, wirklich zu assertieren (wahrscheinlich).
Der Artikel weist auch auf ein großes Problem hin: "Wichtig: Dieser Aspekt von Contracts ist der Grund, warum Vertragszusicherungen nicht zur Fehlerbehandlung und Eingabevalidierung verwendet werden dürfen: Wenn eine Funktion vertragliche Anforderungen hat, bestimmte Ereignisse als Fehler zu melden, muss diese Behandlung mit standardmäßigen C++-Kontrollanweisungen erfolgen, die nicht optional sind, niemals mit Vertragszusicherungen."
Diese Art schwammiger Definition, wofür Contracts verwendet werden sollen, wird mit ziemlicher Sicherheit ein Durcheinander verursachen. Es ist keine Eingabevalidierung, sondern Parametervalidierung ... aber nicht wirklich Validierung, sondern eher Prüfungen, die zu Fehlern führen, aber es sind keine Fehler, die wir erzeugen.
- WalterBright
Ich war früher ein großer Fan von Contracts und habe es sogar im Zortech C++-Compiler in den 90ern implementiert:
https://www.digitalmars.com/ctg/contract.html
Ich habe es auch in D implementiert. Aber es stellte sich einfach als nicht sehr nützlich heraus.
- ZuLuuuuuu
Das erinnert mich an das Konzept "Design by Contract" aus der Programmiersprache Eiffel:
https://en.wikipedia.org/wiki/Design_by_contract
https://www.eiffel.com/values/design-by-contract/introductio...
- Surac
Wofür sind sie überhaupt gut, wenn wir die Eingabe nicht validieren dürfen? Eine bequeme Möglichkeit, Parameterbereiche aufzuschreiben. Mehr nicht.
- gavinray
Zufällige Randnotiz: Ich habe vor Jahren ein GCC-Compiler-Plugin geschrieben, um Contracts zu C/C++ hinzuzufügen, während ich darauf wartete, dass dies in den Standard aufgenommen wird
https://gavinray97.github.io/blog/adding-invariant-to-cpp-de...
Der Beitrag erwies sich letztendlich als nützlicher für eine Einführung in das Schreiben von GCC-Plugins als für alles andere, aber zumindest hatte ich Spaß
- tsukikage
Der Artikel erwähnt keine Optimierungsanwendungsfälle. Falls jemand bereits aus dem Stegreif weiß und bevor ich anfange, nach der Antwort zu suchen: Ist es Teil der Absicht hier, dass diese die Optimierer-Phasen informieren, vielleicht ähnlich wie das Idiom `if (!(some_condition)) { __builtin_unreachable(); }` erreichen kann?
- MetaverseClub
Ich frage mich, was die Anwendungsfälle in ihren Köpfen waren, als sie dies entworfen haben.
Für Laufzeit-Zusicherungen und Dokumentation, ja, es würde funktionieren, aber es funktioniert auch ohne Contract, wohlgemerkt okay.
Für formale Verifikation ist das Design weit daneben.
- randyrand
Vielleicht geht es nur mir so, aber riesige komplizierte Sprachen wie C++ scheinen so unattraktiv wie eh und je.
Wenn ich Code von Hand schreibe, ist die Anforderung nach einer schönen, angenehmen Sprache größer denn je.