C89, C99 |
Im Jahr 1989 wurde der erste
ANSI-C-Standard verabschiedet. Bereits in diesem Jahr gab es Compiler, die diesen Standard explizit beachtet/implementiert hatten. Beispiel: MS-C-386 V5.1 unter SCO-Unix 3.2.0, 1989 gekauft! Im Jahr 1999 wurde der zweite C-Standard verabschiedet: C99 Jedoch bis jetzt, 2003, knapp vier Jahre nach Verabschiedung, gibt es keinen C99-Compiler! U.a. Microsoft und Borland haben offensichtlich nicht vor, C99 jemals zu unterstützen! Warum ist das so?
Ich habe in den zurückliegenden etwa 7 Jahren die C-Szene beobachtet, auf Webseiten, in Newsgroups und in Fachzeitschriften. Daraus ist natürlich ein (Meinungs-)Bild entstanden: Fazit:
Man ist enttäuscht von C99! Man mag diesen Standard nicht! Auch Dennis Ritchie, einer der beiden C-Erfinder, ist gewiß nicht begeistert von C99: http://www.linuxworld.com/linuxworld/lw-2000-12/lw-12-ritchie.html
Kernighan/Ritchie tun sich auch schwer, eine dritte Ausgabe ihres Bucheshttp://www.gotw.ca/publications/c_family_interview.htm zu schreiben. Bisher haben sie es nicht geschrieben! Insbesondere habe ich den Eindruck gewonnen, daß die Compiler-Entwickler C99 nicht mögen!:
unter FreeBSD nur für die Compiler-Exe selbst, nicht für das Entwicklungssystem mit den Libs und den Headern, Linker ... Hier ist die Lage also anders herum wie bei OpenUnix8. Im Library-Bereich hat C99 den Entwickern ein ganz dickes Ei gelegt - unbequem! Bei der Sprache selbst hat sich nicht so viel geändert! Aber gerade hinsichtlich des Letzteren hätten viele Programmierer mehr erwartet! Die meisten C-Programmierer sind enttäuscht von C99! |
Für wen? |
Eine Programmiersprache hat den
Zweck, daß Programmierer mit ihr programmieren! Einen anderen Zweck gibt es nicht. Folglich muß ein Standard primär für die Programmierer arbeiten! Genau das hat C99 nicht in genügendem Umfang getan. In weiten Bereichen hat man sogar gegen die Programmierer festgelegt! In zweiter Linie müssen die Compiler-Entwickler bedient werden. Drittens muß die Entwicklung bei den Prozessoren berücksichtigt werden. Viertens muß die Stellung/Bedeutung der Sprache in der Welt gesichert werden. Der C99-Standard jedoch dreht diese Prioritäten einfach um! Bis vor C99 war C fast zu 100% eine echte Untermenge von C++. Seit C99 ist das nicht mehr so. Und weil das nicht mehr so ist, hätte man die Sprache C gemäß C99 noch viel stärker erweitern/verbessern sollen, entsprechend den Wünschen und Vorstellungen einer Majorität der C-Programmierer! Jedoch C99 wurde viel zu ängstlich festgelegt! |
IMO
|
Die nachfolgende Wunschliste erfordert im wesentlichen nur
Erweiterungen
Beispiele zu Obenstehendem:[ align n ]Portable Bitfelder, auch außerhalb von Strukturen, mit Kommaliste aufgereiht, default=1st_field_is_maschine_aligned, Adresse auf erstes Feld möglich, unsigned|signed geben nur die Signedness an, intern stets als uchar-Array angelegt, vollkommen lückenlos, bit-padding nur am Ende. Auch Bitfeld-Arrays, Bitfeld-Pointer, _Bool-Pointer. int A[10]; //index 0..9
char const a[]= "aaaaaaa"; . |
Anhang
|
Wenige Tage nach Kreation
dieser Seite: Google zeigt nach Eingabe von "better c99" über 12000 Suchergebnisse, wobei diese Seite an erster Stelle aufgeführt wird (international). Wenn in Newsgroups erstmals über diese Seite informiert wird, gibt es jeweils einen kleinen Ansturm. Das Thema dieser Seite ist folglich zweifellos interessant. Bei den Padding-Bits stören mich die Konsequenzen, die sich daraus ergeben. Beispielsweise die Trap-Repräsentationen, der Wegfall von Objekt-Korrespondenzen in unions, usw. Die Padding-Bits sind vollkommen undefiniert. Es ist lediglich bekannt, daß sie vorhanden sein dürfen. Und der Anwender/Programmierer kann nichts damit anfangen! Padding-Bits sind etwa so anzusehen wie ein Prozessor-Status-Register. Unter anderem wegen dieser Gegebenheiten halte ich es für absurd, daß solche Bits in jedem Objekt (außer unsigned char) vorhanden sein dürfen. In C-Newsgroups wird unendlich über Padding-Bits und die ungeahnten(?) Folgen ihrer erlaubten Existenz -immer wieder neu- diskutiert und gestritten. Man träumt schon fast von "Trap representation". Schrecklich, schrecklich, furchtbar! Bitfelder können auf indirekte Weise die Performance
stark steigern! Beispielsweise 22 _Bool-Objekte in einer Funktion können
allesamt in einem einzigen Das gilt teilweise auch für Bitfeld-Arrays, auch wenn
dort die Bitfelder mehr als ein Bit haben. |
Links |