?
Mal zu deiner Liste:
# 1. Warum keine Aufteilung in Basic-C und Full-C? (Wie bei
# PEARL z.B.)
Wir haben "freestanding" und "hosted", außerdem "IEEE Floating
Point" und "non-IEEE FP". Ansonsten Zustimmung, ein paar mehr
solcher "conformance profiles" wäre sicher nicht verkehrt.
# 2. Warum wurde kein Compiler-Schalter gefordert, der die
# Prioritäten von &^| über die der Vergleichsoperatoren
# erhebt?
Nicht gut. Damit hängt die Bedeutung eines Quelltextes von den
Compilerschaltern ab. Also müßte man einen Weg vorsehen, die
Compilerschalter in den Quelltext zu schreiben. Und wenn man
schon am Quelltext rumschreibt, kann man auch gleich richtig
klammern.
Das wäre ein Hack für dumme Programmierer. Genauso könnte man
auch "void main" erlauben, um zur MSDN kompatibel zu werden.
# 3. Die neuen Schlüsselworte _Bool, _Complex, _Imaginary sind
# optisch bizarr!
Wenn's nach mir ginge, hätte man diese Details gar nicht
spezifiziert, sondern einfach definiert, daß das Schlüsselwort
"bool" nur zur Verfügung steht, wenn <stdbool.h> inkludiert wird
- fertig.. Bei <tgmath.h> braucht man auch Compilermagie, die
ist aber nicht vorgeschrieben.
An "complex" stört mich allerdings vor allem, daß es absolut
inkompatibel zu C++ ist. Warum nicht "complex(float)"? Dann wäre
"complex(X)" ein Makro, das zum Komplex-Typ von X expandiert.
In C++ wäre das
#define complex(X) std::complex<X>
und in C99
#define complex(X) _Complex X
# 4. Warum wurde bei _Bool nicht verlangt, daß bei einem
# _Bool-Array mit mehr Elementen als ein Byte Bits hat, ein
# lückenloses Bitfeld angelegt werden muß?
Irgendwie lassen sich die C-Standardisierer nicht dazu
hinreißen, ein Objekt zu erlauben, auf das man keinen Zeiger
legen kann. Ich bin unentschlossen, ob ich das will oder nicht.
# 6. Es ist nichts gegen das neue Schlüsselwort restrict
# einzuwenden, aber auch hier halte ich andere Dinge für
# wichtiger.
IIRC ist "restrict" für Compilerbauer nicht mit Aufwand
verbunden (wer's nicht unterstützen will, ignoriert es). Es
bringt aber mehr Aussagekraft in die Sprache, die bessere
Optimierungen erlaubt. Und das ist gut so (tm).
# 11. Warum kein logisches XOR ^^ ?
Da gibt's nun wirklich wichtigeres XOR erlaubt keine
Kurzschluß-Auswertung, also gibt es keinen Unterschied zwischen
"!a ^ !b" und deinem "a ^^ b".
# 12. Warum keine Potenzier-Operation? (a**3)
Was genau stört dich an "pow"?
# 15. Warum kein Schlüsselwort align ?
# 16. Warum keine portablen Bitfelder? Das ist ganz leicht möglich!
Ich wünsche mir ja einen portablen Pragma-Satz, den man an jedes
Sprachkonstrukt anhängen kann, nach Regeln in der Grammatik. Ein
paar standardisierte Pragmas für Alignment, Padding, Bitfeld-
Anordnung usw. könnte man dann fordern, und wenn die
Implementation sie nicht umsetzen kann, wird das Programm
zurückgewiesen (ist in Ada wohl so).
Die Standard-Pragmas für Floating Point sind schon mal ein
Schritt in die richtige Richtung. Allerdings ist #pragma Murks,
weil man nie weiß, wozu es denn nun gehört. Was bedeutet
#pragma pack(2)
struct
#pragma pack(1)
foo
#pragma pack(4)
{ /* ... */ };
?
Aber C99 hat durchaus auch gute Sachen:
+ VLAs. Daß die noch keiner komplett unterstützt, ist wirklich
schade.
+ "restrict".
+ endlich portable Integer-Typen.
+ "for(int i = 0; i < 100; ++i)".