Viel Spass dabei eine Semantikprüfung für C zu implementieren Aber glücklicherweise ist der Ausdruck "Semantik" ja schwammig genug. Irgendwas wird sich schon finden was da implementiert werden kann. Trotzdem Semantikprüfungen gehören meiner Ansicht nach nicht in den Compiler und am allerwenigsten in eine Compiler-Collection die auch niedere Sprachen wie C/C++ unterstützt. Schade um die schönen Steuergelder!
Das und wie man erweiterte Semantikprüfungen in eine Sprache wie C bringen kann, zeigt das Splint-Projekt. einen ähnlichen Weg könnte GGCC ja auch für alle Sprachen einschlagen.
Von Franz Herbert am Do, 2. November 2006 um 18:46 #
> Das und wie man erweiterte Semantikprüfungen in eine Sprache wie C bringen kann, zeigt das Splint-Projekt. einen ähnlichen Weg könnte GGCC ja auch für alle Sprachen einschlagen.
Die Semantik eines Programms wird durch die Sprache definiert. Wenn der Programmierer statt "flags ^= 0x1234" versehentlich "flags &= 0x1234" hinschreibt ist das kein Semantikfehler.
Statt wie vorgeschlagen "den Code mit Anmerkungen versehen, die bestimmte Eigenschaften ihres Codes beschreiben", sollte man lieber mehr Gründlichkeit beim eigentlichen Programmieren walten lassen.
Nicht dass das jemand falsch versteht. Eine Warnung bei Ausdrücken wie "if (a = b)" ist absolut ok, mehr ist jedoch in meinen Augen Unsinn und nicht realisierbar.
> sollte man lieber mehr Gründlichkeit beim eigentlichen Programmieren walten lassen Man kann ja versuchsweise auch beides machen. Striktere Schnittstellendefinitionen durch Anmerkungen helfen, implizite Vereinbarungen wie "hier immer einen Zeiger auf einen gültigen Speicherbereich übergeben" durch Maßnahmen wie die Null Annotation bereits zur Übersetzungszeit sicherzustellen. Warum denn nicht?
Das ist halt eine Frage der Definition. Wenn man sagt "Je einfacher es ist, sich ins Bein zu schießen, desto niederer die Sprache", dann gehören C/C++ so in etwa zu den Vorderladern.
Schon möglich, kann durchaus kann. Da die meisten hier (ich zähle dazu) jedoch keinen Einblick in die Quellen der M$-Compiler haben dürften und sie wohl auch mangels passendem Betriebssystem nicht verwenden lässt sich das wohl schlecht beurteilen.
... nehme ich doch lieber die D-Programmiersprache, da sind in der Sprache selbst einige Fehlervermeidungsstrategien vorgesehen, Stichwort Design-by-contract. Man kann Invarianten für Klassen, Vor- und Nachbedigungen für Funktionen vorgeben, die zur Laufzeit überprüft werden. Man kann sogar sehr viele Dinge in der Sprache während der Kompilierung prüfen lassen...
Und es gibt einen "unfreien" Referenz-Compiler, sowie einen Port zum GCC, den GDC.
Und was soll das bringen ? Ist schon schlimm genug, dass der Kernel in C, Windowmanager und System-C hingegen in C++ geschrieben wurden. Ich kann mir nicht vorstellen, dass diese babylonische Sprachverwirrung von eventuellen Vorteilen aufgewogen werden kann. Natürlich sind verschiedene Programmiersprachen erforderlich, aber zur Zeit wird das doch nun wirklich zu weit geführt! Also ich finde: entweder C oder was ganz Anderes, aber bitte kein modifiziertes C. OK, ich bin ein DAU, der zu blöd ist, die (Programmier)Sprachen dieser welt zu lernen, und sich nach Standardisierung sehnt, ich verzieh mich schon und geh wieder bei Heise trollen....
Schade um die schönen Steuergelder!
lg
Erik
Die Semantik eines Programms wird durch die Sprache definiert. Wenn der Programmierer statt "flags ^= 0x1234" versehentlich "flags &= 0x1234" hinschreibt ist das kein Semantikfehler.
Statt wie vorgeschlagen "den Code mit Anmerkungen versehen, die bestimmte Eigenschaften ihres Codes beschreiben", sollte man lieber mehr Gründlichkeit beim eigentlichen Programmieren walten lassen.
Nicht dass das jemand falsch versteht. Eine Warnung bei Ausdrücken wie "if (a = b)" ist absolut ok, mehr ist jedoch in meinen Augen Unsinn und nicht realisierbar.
Man kann ja versuchsweise auch beides machen. Striktere Schnittstellendefinitionen durch Anmerkungen helfen, implizite Vereinbarungen wie "hier immer einen Zeiger auf einen gültigen Speicherbereich übergeben" durch Maßnahmen wie die Null Annotation bereits zur Übersetzungszeit sicherzustellen. Warum denn nicht?
lg
Erik
Was soll denn sowas??? ne ne ne ... wohl nie richtig kennengelernt???
Ne ne, sind so toll die Sprachen!!!
Man kann Invarianten für Klassen, Vor- und Nachbedigungen für Funktionen vorgeben, die zur Laufzeit überprüft werden. Man kann sogar sehr viele Dinge in der Sprache während der Kompilierung prüfen lassen...
Und es gibt einen "unfreien" Referenz-Compiler, sowie einen Port zum GCC, den GDC.
Ist schon schlimm genug, dass der Kernel in C, Windowmanager und
System-C hingegen in C++ geschrieben wurden.
Ich kann mir nicht vorstellen, dass diese babylonische Sprachverwirrung
von eventuellen Vorteilen aufgewogen werden kann.
Natürlich sind verschiedene Programmiersprachen erforderlich,
aber zur Zeit wird das doch nun wirklich zu weit geführt!
Also ich finde: entweder C oder was ganz Anderes, aber bitte kein modifiziertes C.
OK, ich bin ein DAU, der zu blöd ist, die (Programmier)Sprachen dieser welt zu lernen,
und sich nach Standardisierung sehnt, ich verzieh mich schon und geh wieder bei Heise trollen....