[Allegro] Neue Pferde

[Bernhard Eversberg]

Am 30.07.2012 15:34, schrieb Ralf Kretschmer:
>
> Am 30.07.2012 14:34, schrieb Thomas Berger:
>> Das waere dann aber
>>
>> w "Zugang"
>>
>> ohne den Versuch, ein ASCII-0 in den Daten unterzubringen. Evtl. liegt
>> es ja bereits daran?
> Ja, offensichtlich. Steht aber so im Handbuch S. 263 "Ohne die "0" waere
> kein Endezeichen da..." Herr Eversberg konnte ja eine Interimsloesung
> anbieten - die funktioniert.
>

Mit V32.7 wird ein import.exe geliefert, das der ärgerlichen Kalamität
ledig ist.
Es handelte sich, wie schon geschrieben, um eine rare Inkonsistenz der 
Compiler, die wir nun überwunden haben.

Die 0 ist immer dann wichtig, wenn in dem Moment im Arbeitstext etwas
steht, was jedoch nicht mit in den Ausgabetext soll. Denn der w-Befehl
setzt etwas VOR den AT, läßt diesen aber intakt, so daß der Ausgabetext
dann die "Verkettung" von dem mit w angegebenen und dem aktuellen AT
ist. Der Code 0 jedoch beendet jede Zeichenkette in C, und das hat zur
Folge, daß im AT nur das steht, was mit w angegeben wurde.

N.B.
Die Sonderfunktion des Codes 0 gibt es z.B. in Java nicht. Eine Import-
Sprache mit einem in Java programmierten Interpreter würde ganz anders
aussehen, aber bestimmt nicht nur aus diesem Grunde. C war zur Zeit
der Entstehung des 16bit-allegro-Systems tonangebend, jetzt nicht mehr.
Aber auch C++ mit einer String-Klasse wie CString (in WFC) hat schon
andere Qualitäten, wie etwa die Verpönung der Arbeit mit Zeigern, die
in Java gleich gar nicht mehr möglich ist. Unsere C++-Programme sind
nicht so weit gegangen, die Klasse CString einzusetzen statt der
alten Strings! Einerseits, weil das die Umstellung gewaltig erschwert
hätte, andererseits, weil dann die Compilierung unter Linux/UNIX mit
GNU nicht mehr unproblematisch wäre. Von Performanz nicht zu reden,
die hätte auch gelitten wegen des notwendigerweise extremen Umfangs der
Stringverarbeitung in allen allegro-Programmen.


MfG B.Eversberg