4. Better C99 - Meine Wunschvorstellung

Better C99 - Meine Wunschvorstellung

  • ?

    http://www.schellong.de/better_c99.htm

    0
  • ?

    Da hält sich einer für ganz wichtig.

    0
  • S

    absoluter schwachfug was der typ da schreibt.

    mit einer ausnahme: C99 ist nicht so der hammer. es haette mehr fokus auf den embedded bereich gelegt werden muessen und der standard kam zu spaet.

    aber die geforderten punkte sind groesstenteils schwachfug...

    0
  • N

    Shade Of Mine schrieb:

    absoluter schwachfug was der typ da schreibt.

    findste? naja, er übertreibt's etwas, aber mit einem schlüsselwort 'align' könnte man z.b. struct-members auf bytegrenzen zwingen. wär doch gut wenn's sowas gäbe, statt immer verschieden #pragmas benutzen zu müssen.
    auch mit dem _Complex und _Bool hat er recht. das ist wirklich entbehrlich...

    0
  • S

    net schrieb:

    findste?

    jo.

    align waere nett. stimmt.
    aber zB die range sachen?
    schluesselworte seien bizarr
    etc.

    nicht alles ist kompletter schwachsinn was er sagt, aber das meiste ist es. und keine seiner punkte ist ein "killer feature" das fehlt.

    bitfelder und align sind wohl die einzigsten sachen die ich von seinen punkten ueberhaupt haben wollen wuerde.

    0
  • C

    der versucht aus C etwas zu machen, was es nie war und nie sein wird.
    was seinen vorstellungen naeher als C kommt ist 😨 http://www.digitalmars.com/d/

    0
  • ?

    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)".

    0
Anmelden zum Antworten