G
Optimizer schrieb:
Höh? Weil es nicht abgedeckt ist, ist es egal?
Exakt! Wenn ich auf einem System nicht so arbeiten kann, wie es der Standard vorschreibt, dann ist mir bewusst, dass ich nicht plattformunabhängig bin. In so einem Fall ist es mir persönlich egal, wenn ich Code habe, den ich auf anderen Systemen nicht einfach so wiederverwenden kann. Ich glaube aber auch nicht, dass ich mit irgendeiner Sprache Anwendungen schreiben kann, die wirklich auf _allen_ Systemen laufen.
Optimizer schrieb:
Ja sind sind eindeutig implementation-defined definiert. Warum behauptest du, das sei irrelevant? Es ist äußerst unglaubwürdig, "write once, run anywhere" zu postulieren und dann zu behaupten dass Unterschiede in der Arithmetik irrelevant sind. Unterschiede in der Arithmetik verändern das Verhalten deines Programms und sind für die Semantik eines Programm höchst relevant. Du musst es umschreiben, damit es sich auf der neuen Plattform wie gewohnt verhält.
Ersten, du denkst zu viel low-level. Wir reden hier immer noch über C++ und nicht über Assembler. Und zweitens, es gibt keine Unterschiede in der Arithmetik, höchstens Spezialfälle. Wie ich schon sagte, die Operatoren sind eindeutig definiert. Hier nur mal ein kleiner Auszug als Beispiel:
The binary * operator indicates multiplication.
Multiplikation bedeutet nunmal Multiplikation. Und ich verstehe das im mathematischen Sinne. Kann sein, dass du das anders verstehst. Ich kenne allerdings nichts anderes. Letztendlich bedeutet das, dass zB 5 multipliziert mit 3 immer 15 ergibt. Nicht 14 und auch nicht 16, sondern exakt 15. Wie letztendlich die Darstellung der Werte auf Bitebene aussieht oder wie die Prozessorbefehle für die Rechnung aussehen, sind mir doch vollkommen egal. Es mag ja sein, dass es CPUs gibt, die solch exotische Ergebnisse wie bei deinem Beispiel ausspucken. Dass es mathematisch trotzdem korrekt ist, darum hat sich der Compiler zu kümmern. Wie er das macht und welche Kombinationen von Befehlen er benutzt, ist seine Sache. Ich sag es nochmal, wir reden bei C++ immer noch von einer Hochsprache und nicht von irgendwelchen Assembler Exzessen. Und sollte ein Compiler das nicht packen, dann, wie Artchi schon sagte, ist er nicht brauchbar.
Optimizer schrieb:
Darauf wollte ich nicht hinaus. Die Header können unterschiedlich implementiert sein, z.B. könnte die Implementierung von <string> den Header <cstring> inkludieren, bei einem anderen Compiler aber nicht. In einem Programm, wo ich jetzt <string> inkludiere, steht mir dann strcpy() vielleicht zur Verfügung, vielleicht auch nicht.
Das ist doch vollkommen bedeutungslos. Du hast meinen Beitrag überhaupt nicht verstanden. Der Standard spezifiziert für alles Mögliche die zugehörige Headerdatei. Wenn du also strcpy() brauchst, dann hast du gefälligst <cstring> einzubinden. <string> interessiert hier keine Sau.
