Ab 8:00 anfangen zu scannen

[TogoTiger]

Ja klar, der nimmt doch den ASCII-Wert Byte um Byte.
Dann ist eben
2 > 1 2 = ASCII 50, 1 = ASCII 49
B > A B = ASCII 60 A = ASCII 65
a > A a = ASCII 97 A = ASCII 65

Damals, in Assemblerzeiten oder noch früher, in Maschinensprache (ja, habe ich noch gemacht), haben wir das doch auch so programmiert.

@Traderdoc: Ich denke nicht, dass der Compiler den String analysiert und in ein Datumsformat umwandelt. Dann spielt es auch keine Rolle, wie lang die Strings sind. Das erste Zeichen, auf das die Bedingung zutrifft, bezw. nicht zutrifft, gibt dann true oder false.
Wenn du jetzt die Zeit in einen String umwandelst und dafür schaust, dass die Stellen stimmen (also nicht 10:00 mit 9:00 vergleichen), dann gibt das doch keine Probleme. Oder irre ich mich da?

[AVT]

Zitat von traderdoc

...
string Zeit = "45";
if (Zeit > "99" || Zeit < "5") {
Print ("Kein Handel. Zeit: ",Zeit);
return;
}
Print ("Handel. Zeit: ",Zeit);
}
ergibt ein true!?
Reihenfolge: 4 - 45 - 99 ==> 45<99 45<5 weil 4(5) vor 5 kommt

string Zeit = "55";
if (Zeit > "99" || Zeit < "5") {
Print ("Kein Handel. Zeit: ",Zeit);
return;
}
Print ("Handel. Zeit: ",Zeit);
}
Reihenfolge: 5 - 55 - 99 ==> 55<99 55>5 weil 5 vor 55 kommt
ergibt ein false, was in gewisser Weise evtl. noch logisch wäre, weil 55 zwischen 99 und 5 liegt. (Nur 45 ja auch!)

Aber warum der boolsche Logikwechsel zwischen 45 und 55??
Es scheint also so, dass die Strings immer vergleichbar ist, wenn die Zahlen dieselbe Anzahl Stellen besitzen.

Wir haben es hier mit einem reinen string Vergleich von links nach rechts zu tun. Reihenfolge: vergleiche 1.Stelle, vergleiche 2.Stelle, vergleiche 3.Stelle ... So sehe ich das. AVT

[AVT]

Zitat von TogoTiger

Ja klar, der nimmt doch den ASCII-Wert Byte um Byte.

Ich glaube nicht, daß hier mit ASCII-Werten gearbeitet wird, MT kann UTF und das geht über ASCII hinaus, aber wie das auf der untersten Ebene (also Maschinencode) gemacht wird, hab ich keine Ahnung. AVT

[TogoTiger]

Da bin ich mir nicht so sicher, ob bei MT4 Strings immer UTF-Zeichen sind, also zwischen 2 und 4 Byte pro Zeichen. Da müsste ich mich schon genauer damit beschäftigen. Ist aber egal, dann wird halt UTF-Zeichen um UTF-Zeichen verglichen, nicht Byte um Byte.

[traderdoc]

In der Tat:

string Zeit = "6";

if (Zeit > "10" || Zeit < "5") {
Print ("Kein Handel. Zeit: ",Zeit);
return;
}
Print ("Handel. Zeit: ",Zeit);
}
Hier ist die 6 aber größer als die 1 der 10 und somit als Ergbnis false.


string Zeit = "45";

if (Zeit > "99" || Zeit < "5") {
Print ("Kein Handel. Zeit: ",Zeit);
return;
}
Print ("Handel. Zeit: ",Zeit);
}
ergibt ein true, weil die 4 der 45 kleiner ist als die 5.

Ok, ich habe das Prinzip verstanden, man muß aber höllisch aufpassen und damit ist die Methode extrem fehleranfällig.

Gut zu wissen, aber außer beim Zeitvergleich im Format HH:MM werde ich die Strings nicht vergleichen.

traderdoc

[TogoTiger]

Klar Traderdoc, du kommst aus einer andern Ecke der Programmierwelt. Bei mir waren Stringvergleiche jahrzehntelang mein täglich Brot. Da passieren dann mit der Zeit keine Fehler mehr .
Wir haben oft mit indizierten Dateien gearbeitet, da haben wir die Keyfelder immer in Strings gespeichert. War halt einfach zum Debuggen, wenn man bei zusammengesetzten Keys alle Werte in Strings hatte. Und funktionieren tuts, ich betreue heute noch Software, die ich mal vor bald 40 Jahren geschrieben habe. Ist immer noch in Betrieb, mit einem biologischen Ablaufdatum (bin 71 Jahre alt).
Strings sind aber auch nicht sehr effizient. Wer Wert darauf legt, solls besser bleiben lassen.

[Ca$hDigger]

Ich denke auch da steckt intern sowas wie ein strcmp() und damit ASCII dahinter, ist also Lexikographisch vergleichbar.
https://www.geeksforgeeks.org/strcmp-in-c-cpp/

"Zweckmäßigerweise sind die Inhalte zweier Speicherstellen (Bytes) auf der untersten Maschinenebene immer miteinander (im Sinne einer Totalordnung) vergleichbar. Zweckmäßigerweise sind die Ziffern resp. Buchstaben den Bitkombinationen eines Bytes so zugeordnet, dass diese Ordnung mit der üblichen Ordnung im Ziffernsystem resp. Alphabet übereinstimmt. Aufbauend auf diesem Grundbaustein eines Vergleichs lassen sich durch lexikographische Zusammensetzung zusammengesetzte Datentypen, beispielsweise mehrstellige Zeichenketten, miteinander vergleichen.

Korreliert die lexikographische Indizierung mit den Speicheradressen, hat also das beim Vergleichen höherrangige Byte die niedrigere Adresse, dann geschieht der Vergleich im Big-Endian-Stil, und im Little-Endian-Stil, wenn das höherrangige Byte die höhere Adresse hat. Da sich der lexikographische Vergleich im günstigsten Fall schon im ersten, höchstrangigen Byte entscheidet, ist er schneller, wenn dieses erste Byte im unmittelbaren Zugriff liegt. "
https://de.wikipedia.org/wiki/Lexiko...der_Informatik

Zitat von TogoTiger

Strings sind aber auch nicht sehr effizient. Wer Wert darauf legt, solls besser bleiben lassen.

Da es zumindest in dieser Form auf unterer Maschinenebene vergleichbar ist, würde ich sogar sagen das es wahrscheinlich sogar deutlich performanter ist als die Umwandlungen von Strings in Unix-Zeitstempel und der Vergleich darüber. Hinter den Umwandlungen steckt vermutlich sowas wie ein struct tm bzw mktime struct tm - C++ Reference / http://www.cplusplus.com/reference/ctime/mktime/ und das ist auf keinen Fall effizient.

[TogoTiger]

Ja, der Vergeich an sich geht natürlich schnell, aber heute werden Strings doch über Stringconstructors angesprochen und die sind mit Aufwand verbunden (erstellen des Constructors, Platz wieder freigeben etc.)
Das war zu Anfangszeiten einfacher. Man wusste den Anfang des Strings, konnte das entsprechende Byte direkt ansprechen und Ende des Strings war das erste ASCII 0. Nichts mit geschützen Speicherbereichen und pipapo. Und man hatte alle Möglichkeiten für fiese Spielchen
Aber ich habe nur eine vage Ahnung davon, wie das heute genau gehandhabt wird. Ist schon lange, sehr lange her, dass ich da eingehend Bescheid wusste.
Wenn ich mir manchmal neue Programme anschaue wird mir schwindelig, wie grosszügig mit Ressourcen umgegangen wird. Kostet ja auch nichts mehr. Nicht mehr 2000$ pro 1 bis 2 KB, wie zu meinen Anfangszeiten. Ja Kilobyte, nicht Giga oder sowas. Und das waren erst noch viel teurere Dollars.