16-04-2006, Sunday-22:57:37
Das ist ja richtig übel, dass die Datentypen nicht typsicher sind.
Das Ganze sieht in der Tat nach einem Überlauf aus, der,
nachdem man sein Konto überzogen hat, ausgelöst wird
und zudem noch anfängt zu oszilieren.
Das Oszilieren findet im Monatsrythmus zum jewiligen 1. statt.
Sobald der negative Betrag wieder ausgeglichen wurde,
sind die 92... negativ.
Anscheinend immer zu Null.
Beispiel:
-92.... + 20 000 = 0
oder
-20 000 + 92.... = 0
@sojo
Da eine Typsicherung einzubauen ist nicht ganz trivial.
Nehmen wir ein unsigned Byte als Beispiel. Der Zahlenraum geht von
0-255. Was passiert, wenn ich 255+1 rechne?
Natürlich sollte 256 als Ergebnis rauskommen. Das ist aber größer als 8 Bit
und das Ergebnis wird 0 sein (Überlauf). Verhält sich der Datentyp wie gerade beschrieben, so gilt er nicht als typsicher.
Erhält man dagegen als Ergebnis 255 + Fehlermeldung, so wird das als typsicher gewertet.
Jetzt rechne ich aber nicht immer mit + und - und müsste bei jeder Rechnung prüfen, ob ich die Rechnung
a = b + c oder a = b * c etc. überhaupt ausführen darf.
Eine Prüfung könnte für eine Addition dann vereinfacht so aussehen:
if (( 255 - b) > c )
a = b + c;
else
ERROR();
(vorausgesetzt, b ist gültig und hat z.B. selbst keinen Überlauf erfahren)
Ähnliches müsste dann natürlich auch für die anderen Rechenoperationen
erstellt werden.
Eine Simulation strotzt natürlich von Berechnungen und wenn jede Operation vorher abgeprüft werden, leidet die Performance
erheblich.
Natürlich gibt es auch Tricks;
unsigned int a;
unsigned BYTE b, c;
....
a = b + c;
Damit umgeht man einen Überlauf.
Oder, bei einer Rechnung m / n kann n = 0 werden. m / 0 = Problem
Trick: m / ( n + 1) ....
Prissi und seine Leute werden den Fehler schon finden.
Das Ganze sieht in der Tat nach einem Überlauf aus, der,
nachdem man sein Konto überzogen hat, ausgelöst wird
und zudem noch anfängt zu oszilieren.
Das Oszilieren findet im Monatsrythmus zum jewiligen 1. statt.
Sobald der negative Betrag wieder ausgeglichen wurde,
sind die 92... negativ.
Anscheinend immer zu Null.
Beispiel:
-92.... + 20 000 = 0
oder
-20 000 + 92.... = 0
@sojo
Da eine Typsicherung einzubauen ist nicht ganz trivial.
Nehmen wir ein unsigned Byte als Beispiel. Der Zahlenraum geht von
0-255. Was passiert, wenn ich 255+1 rechne?
Natürlich sollte 256 als Ergebnis rauskommen. Das ist aber größer als 8 Bit
und das Ergebnis wird 0 sein (Überlauf). Verhält sich der Datentyp wie gerade beschrieben, so gilt er nicht als typsicher.
Erhält man dagegen als Ergebnis 255 + Fehlermeldung, so wird das als typsicher gewertet.
Jetzt rechne ich aber nicht immer mit + und - und müsste bei jeder Rechnung prüfen, ob ich die Rechnung
a = b + c oder a = b * c etc. überhaupt ausführen darf.
Eine Prüfung könnte für eine Addition dann vereinfacht so aussehen:
if (( 255 - b) > c )
a = b + c;
else
ERROR();
(vorausgesetzt, b ist gültig und hat z.B. selbst keinen Überlauf erfahren)
Ähnliches müsste dann natürlich auch für die anderen Rechenoperationen
erstellt werden.
Eine Simulation strotzt natürlich von Berechnungen und wenn jede Operation vorher abgeprüft werden, leidet die Performance
erheblich.
Natürlich gibt es auch Tricks;
unsigned int a;
unsigned BYTE b, c;
....
a = b + c;
Damit umgeht man einen Überlauf.
Oder, bei einer Rechnung m / n kann n = 0 werden. m / 0 = Problem
Trick: m / ( n + 1) ....
Prissi und seine Leute werden den Fehler schon finden.