inifile ReadFloat deutsch/english formatsettings

[freimatz]

Pointer sind bei uns - zum Glück - zu Recht - verboten.
Wenn es um Datum geht würde ich das in ANSI-Format speichern. Aber Fragenden ging es wohl um "normale" Double.

Zitat von himitsu:

Erstmal ist es totaler Schwachsinn, dass INIs überhaupt lokalisiert gespeichert/gelesen werden.
(aber für INIs gibt es ja leider auch eigentlich keine globale einheitliche Konvention/Richtline/Norm/...)

Ist das bei XML und/oder JSON anders?

[Rolf Frei]

Ja. XML kann über einen Header bestimmt werden, was für eine Codierung gilt. Ohne den Header ist es per Definition UTF-8. JSON ist nach meinem Wissenstand per Definition immer UTF-8.

[Redeemer]

Zitat von Rolf Frei:

Ja. XML kann über einen Header bestimmt werden, was für eine Codierung gilt. Ohne den Header ist es per Definition UTF-8. JSON ist nach meinem Wissenstand per Definition immer UTF-8.

Um Zeichenkodierung geht es hier nicht.

[jziersch]

Hier als Lösungsvorschlag eine Funktion ConvertStr um einen String in ein Double zu verwandeln
und dabei . und , alternativ zu akzeptieren sowie spaces zu ignorieren.
Um INI Dateien zu lesen meiner Ansicht nach recht zweckmässig, um beim Start eines Programmes Exceptions zu vermeiden.

Code:

function ConvertStr( const str : string ) : Double;
var i : Integer;
    fNeg, fDez : Boolean;
    c : Char;
    fN, fDD : Double;
begin
      fN := 0;
      fNeg := FALSE;
      fDez := FALSE;
      fDD := 10;
      for i := 1 to Length(str) do
      begin
        c := str[i];
        if c = '-' then fNeg := not fNeg
        else if c = '.' then fDez := true
        else if c = ',' then fDez := true
        else if c in ['0'..'9'] then
        begin
          if fDez then
          begin
            fN := fN + (Integer(c) - Integer('0'))/fDD;
            fDD := fDD * 10;
          end else
          begin
            fN := fN * 10 + (Integer(c) - Integer('0'));
          end;
        end
        // Wenn auskommentiert werden unerwartete Zeichen einfach ignoriert
        // else break
        ;
      end;
      if fNeg then Result := -fN
      else Result := fN;
end;

[himitsu]

XML nein, da sind Floats garnicht gefiniert (alles als String und das Format ist nicht vorgegeben)

aber JSON ja, denn dort ist ALLES ganz genau definiert, zumindestens bei Sting, Boolean, Integer und Float. (fast, denn beim Datum gibt es zwar indirekt eine Quasi-Vorgabe, aber Datum als "Typ" gibt es das per-se nicht)
https://www.json.org/json-de.html

[Rolf Frei]

Zitat von Redeemer:

Zitat von Rolf Frei:

Ja. XML kann über einen Header bestimmt werden, was für eine Codierung gilt. Ohne den Header ist es per Definition UTF-8. JSON ist nach meinem Wissenstand per Definition immer UTF-8.

Um Zeichenkodierung geht es hier nicht.

Ja hast natürlich recht. Hatte gedacht weil es um definierte Vorgaben geht. Wenn man aber Doubles,Floats, etc. speichert sollten diese der ANSI Regeln für die Zahlandrestellung nutzen oder multipliziren mit 100 oder sawas. Bei allen XML die ich bisher verabreiten musste, wurde vom Interface (Producer des XML) vorgegeben, dass es mit 100 Multipliziert werden muss (im Fall von Geldbeträgen) oder aber der Punkt als Pflicht vorgegeben ist. Bei Datumsangaben ist es übrignesn das selbe. Die Daten in lokalen Format zu speichern ist aber auf jeden Fall unzulässig und falsch.

[freimatz]

Und was sind die ANSI-Regeln für Zahlendarstellung?
Wen ich google nach "ansi Zahlendarstellung" komme ich z.B. auf https://de.wikipedia.org/wiki/IEEE_754

[himitsu]

IEEE754 ist für das interne Speicherformat innerhalb des Speichers.

Aber passend zu diesem Format gibt es.
https://www.oreilly.com/library/view...2521/re67.html

[Rolf Frei]

Zitat von freimatz:

Und was sind die ANSI-Regeln für Zahlendarstellung?
Wen ich google nach "ansi Zahlendarstellung" komme ich z.B. auf https://de.wikipedia.org/wiki/IEEE_754

Finde gerade auch nichts Vernünfitges, aber es entsprcht eigentlich grösstenteils dem US Format, also wie folgt:
DezimalSeparator = .
ThousandSeparator = ,

Der ThousandSeparator würde ich aber beim Speichern der Zahl immer weglassen und nur den Punkt als Dezimalzeichen verwenden. Beim Einlsende der Daten muss einfach klar sein, wie diese Zahlen vorliegen und das dann entsprechend behandelt werden. Ich mache das immer nach mienem Beispiel, das ich gepostet habe. Thread spielen bei mir dabei keine Rolle, da ich sowas nicht in einem Thread nutze. Da müsste man das dann anders lösen.

[Redeemer]

Zitat von freimatz:

Wenn es um Datum geht würde ich das in ANSI-Format speichern. Aber Fragenden ging es wohl um "normale" Double.

Es gibt keinen Unterschied zwischen TDateTime und Double. Es sind einfach zwei Begriffe für exakt dasselbe, nämlich IEEE-754-Double. Nur die Darstellung von generischen Double-Werten als Datum ist nicht so toll, da u.U. ungültig (max 9999?).

Zitat von freimatz:

Pointer sind bei uns - zum Glück - zu Recht - verboten.

Und mit Windows kommuniziert ihr in Morsecode?
Es gibt halt keinen verlustfreien Weg, eigentlich inkompatiblen Speicher zu casten.