string to Float, für lesen aus einer Datei

[Neumann]

Es gibt dann aber noch folgende Schreibweise für Zahlen, die berücksichtigt werden müssten:

10,000,000.34 oder ev. auch 10.000.000,34

[markus5766h]

Zitat von Neumann:

Es gibt dann aber noch folgende Schreibweise für Zahlen, die berücksichtigt werden müssten:

10,000,000.34 oder ev. auch 10.000.000,34

. . . siehe Post #2 :
"Mehrere Vorkommen des Dezimalseparators innerhalb eines einzelnen Wertes sind ja eh nicht zulässig, ..."

bei "10.000.000,34" könnt' ich mir glatt überlegen, ob dies eine IP-Adresse sein soll

aber mal ernsthaft : ich hab' solche Schreibweisen mit mehreren Separatoren auch schon gesehen und dann gegrübelt, was das denn nun sein soll - man kann von einer Software nicht erwarten, dass sie die Absicht oder Meinung desjenigen errät, der sich bei der Schreibweise von Zahlenwerten nicht an gängige Normen hält.
Im obigen Beispiel fallen mir gleich 4 mögliche Lösungen ein, die ich dann abfragen bzw. auswerten müsste . . .

[KodeZwerg]

Zitat von markus5766h:

"Mehrere Vorkommen des Dezimalseparators innerhalb eines einzelnen Wertes sind ja eh nicht zulässig, ..."
Im obigen Beispiel fallen mir gleich 4 mögliche Lösungen ein, die ich dann abfragen bzw. auswerten müsste . . .

Ich bin der Meinung das bei dem Beispiel nur ein Dezimalseperator vorhanden ist.
Als Lösung für so eine Situation schwebt mir so etwas vor:
String in einer Schleife nach "." und "," suchen lassen, das zuletzt gefundene wird als Seperator genommen, im gleichen Atemzug werden die 100'er Markierungen entfernt.

[Delphi.Narium]

Und was passiert hierbei?

1.001
1,001
100,001
100.001

Was ist jetzt Eintausendeins und was Einskommanullnulleins?
Was ist Einhundertkommanullnulleins und was Einhunderttausendeins?

Für eine sichere Erkennung des Dezimalseparators benötigt man mindestens zwei Tausenderseperatoren und damit Werte über einer Million.

[KodeZwerg]

Ich verstehe was Du meinst, da wird es schnell chaotisch.
Na dann Fragen wir doch mal den TE ob 1000'er Markierungen überhaupt vorliegen.

So hier könnte man testen ob eine Konvertierung gelingt bevor man es konvertiert:

Code:

funtion TestFloatStr ( S : String ) : Boolean;
begin
  try
    StrToFloat(s); // normal aufrufen
    result := true; // scheint keine Exception auszulösen also ist Wert gut
  except
    result := false; // oh-oh, fehler!
  end;
end;

[Uwe Raabe]

Zitat von KodeZwerg:

So hier könnte man testen ob eine Konvertierung gelingt bevor man es konvertiert:

Oder man benutzt gleich TryStrToFloat oder Double.TryParse mit den erwarteten FormatSettings . Das hat den Nebeneffekt, daß es auch gleich konvertiert, wenn das denn möglich ist.

[KodeZwerg]

Das mit dem Double.TryParse war mir neu und klingt interessant, ich habe jetzt ein wenig darüber gelesen, per CultureInfo/InvariantCulture kann man das "." und "," Problem in den Griff bekommen. Aber wenn die Quelle gemixt ist, da hilft sowas auch nicht weiter, vermute ich, Danke für den Tipp!