Zitat von
jbg:
Zitat von
Panthrax:
Was geht mich C an!?
Es ist nicht nur in C so. Auch Java und C# machen das so.
Und wenn alle anderen aus dem Fenster springen...
Zitat von
jbg:
Zitat:
Wenn die schon das Problem erzeugen, wie lösen die es denn!?
Wer? Microsoft oder Embarcadero? Und welches Problem?
Das ist "ein Problem", welches eigentlich keins sein sollte. Ich sehe diese Wolken am Horizont:
Der vorhandene Quelltext mit Zeigerarithmethik muss geändert werden, wenn Pointer mitwächst, Integer aber nicht: Inc(Integer(Ptr));. Besonders hier sehe ich viel Spaß, denn der Kompiler sagt erstmal nichts dazu, und wenn die oberen 32 Bit des Zeigers unterschlagen werden, kommt es vielleicht nicht einmal immer zum Fehler. Wer nicht weiß, wonach er sucht, wird hier echt viel Zeit lassen, da es auch aus Gewohnheit so leicht zu übersehen ist.
Wenn dann einmal ein 64-Bit-Kompiler verfügbar wird, erzeugt dieser doch nur Mogelpackungen, wenn das Programm keine 64-Bit-Datentypen verwendet, obwohl es das könnte. Was soll werden, wenn es einmal 128-Bit-Prozessoren gibt? -- Nur mal so gesponnen.
Zu guter letzt, welches Vertrauen kann man noch entgegenbringen, wenn man sich nicht einmal auf solch fundamentale Aussagen verlassen kann!?
Java und C# sind sicherlich nicht der beste Vergleich, wenn es um Zeiger geht. Aber wie machen es denn C, Java und C#, wenn es darum geht aus einem Quelltext eine 32- und eine 64-Bit-Anwendung zu erstellen? Wie stellt man sich das vor, wenn sich die Registerbreite ändert: gleicher Quelltext anderes System?
Zitat von
jbg:
Zitat:
Weiß vielleicht jemand, wo man etwas gegen diesen Blödsinn tun kann, Integer bei 32 Bit einzufrieren?
15+x Jahre in die Vergangenheit reisen und den Windows-Programmierern sagen, dass sie statt INT und LONG lieber INT32 und INT32 benutzen sollen.
Ich habe es befürchtet...
Trotzdem, was soll das!? Jetzt muss die Delphigemeinde ausbaden, was C-Idioten verplant haben!? Sollen die doch ihre Datentypen ändern! -- Was geht mich C an!?