Zitat von Mikkey:

Was bedeutet die Aussage der Online-Hilfe?

Das bedeutet, dass dir FloatToStr u. U. um die Ohren fliegen kann, weil irgendwer für den Preis 3,95 Euro in das Feld 3,95 eingibt (mit Komma), im System aber als Dezimaltrennzeichen ein Punkt (.) eingetragen ist und dein Programm deshalb ein 3.95 erwarten (mit Punkt).

Das FloatToStr richtet sich immer nach dem im System eingetragenem Dezimaltrennzeichen, was an für sich keine schlechte Idee ist. Das kann aber gelegentlich zu Problemen führen. Hier bist also nicht du der Herr über das Dezimaltrennzeichen in deinem Programm, sondern das System.

Wieso man das nun mit Thread-Sicherheit beschreibt fällt mir nicht ein. Gemeint ist aber damit, dass es u. U. zu Fehlermeldungen kommt wenn ein falsches Zeichen eingegeben wird. Mit der zweiten Form kann man nämlich FloatToStr mitteilen welches Dezimaltrennzeichen er beachten soll. Ein Beispiel:

markieren

Delphi-Quellcode:

var
  fs: TFormatSettings;
  s: string;
begin
  fs.DecimalSeparator := ','; //falls Komme erwünscht
  s := FloatToStr(3.95, fs);
  ShowMessage(s);
end;

Zitat von Popov:

Wieso man das nun mit Thread-Sicherheit beschreibt fällt mir nicht ein.

Naja, angenommen du gewöhnst dir einfach an, immer am globalen Decimal-Separator herumzuspielen wenn du es grade brauchst dann bekommst du ein Problem wenn du anfängst mit mehreren Threads zu arbeiten.

Die Hilfe erzählt manchmal gerne
Das beste ist, wo sie irgendwo zu Methoden eines TDataSets anfangen zu erklären, was eigentlich virtuelle Methoden sind. Wenn man ja schon dabei ist...

Alle Funktionen, die z.B. mit den FormatSettings arbeiten sind nicht threadsafe, denn der interne Aufruf sieht so aus:

markieren

Delphi-Quellcode:

function FloatToStr(Value: Extended): string;
begin
  Result := FloatToStr(Value, FormatSettings); // GLOBALE Variable FormatSettings wird benutzt
end;

Und eine globale Variable ist nun mal nicht threadsafe (es gibt da Ausnahmen, aber die wollen wir mal aussen vor lassen), denn in diese kann man jederzeit von überall einfach reingreifen und verändern.

Korrekt wäre es einem Thread eine eigene FormatSettings Variable zu verpassen, die dann innerhalb des Threads verwendet wird.

Zitat von Popov:

Das bedeutet, dass dir FloatToStr u. U. um die Ohren fliegen kann

Ich habe mit Absicht nach FloatToStr gefragt, nicht nach StrToFloat . Ersteres fliegt einem in der Regel nicht um die Ohren.

Zitat von Popov:

Wieso man das nun mit Thread-Sicherheit beschreibt fällt mir nicht ein

Genau darum dreht sich aber die Frage, kann man sich auf die Umkehrung der OH-Aussage verlassen?

@mkinzler:
Üblicherweise können Daten, die nur gelesen werden, ohne Weiteres zwischen verschiedenen Threads geteilt werden.

@Günther:
Das macht Sinn, müsste dann aber auch den Schluss zulassen, dass ich mit einer einzelen FormatSettings-Struktur auch in mehreren Threads arbeiten kann?

Das Hauptproblem ist doch, dass man die Zugriffe auf eine gemeinsame Struktur nicht kontrollieren kann. Man muss im gesamten Programm höllisch aufpassen, da nicht irgendwie reinzugrätschen um dadurch die lustigsten Fehler zu erhalten: "Geht meistens, aber nicht kurz nach Sonnenuntergang!"

Das ist das Salz in der Suppe beim Multi-Threading!

Zitat von Mikkey:

Üblicherweise können Daten, die nur gelesen werden, ohne Weiteres zwischen verschiedenen Threads geteilt werden.

Man kann sich noch darüber streiten, ob das Starten eines Threads eine Synchronisation ist

Zitat von Sir Rufo:

Das ist das Salz in der Suppe beim Multi-Threading!

Und Speichersemantik sind die Speckgrieben.

Zitat:

nicht threadsicher

Ohne den Settings-Parameter gehen diese Funktionen auf die globale FormatSettings-Variable
und was ein nicht abgesicherter Zugriff auf globale Variablen bedeutet, daß verstehst du doch?
Vorallem wenn während dessen irgendwer diese Variable mal wieder bösartig verändern könnte.

Es geht mir nicht darum, dass ich die globale Variable verwenden möchte, sondern darum, ob der Umkehrschluss, dass bei einer eigenen Variablen, die von allen Threads lesend(!) verwendet wird, Probleme auftreten können. Fall ja: Reicht eine flache Kopie der Struktur oder muss sie komplett neu erzeugt werden.

Als Hinweis:
Die vereinfachten Methoden FloatToStr etc. sind in C++ eh nicht verwendbar, weil die globalen Variablen DecimalSeparator etc. nicht verfügbar sind und auch über TFormatSettings::DecimalSeparator nicht ansprechbar.

Wenn du die erweiterte Version nimmst und in mehreren Threads aufrufst, dann trifft genau das Selbe zu ... nur halt in einem kleineren und abgegrenzteren Raum, welchen nur du kontrollierst.

Nur Lesen ist weitestgehenst thread-save, wobei die globale Variable, z.B. durch ein WM_WININICHANGE, sich urplözlich mal ändern könnte.
Die Referenzzählung von LongStrings ist thread-save implementiert. (was hier also z.B. die DateFormat-Strings betrifft)

Vielen Dank, das war das, was ich wissen wollte.

Die Möglichkeit der flachen Kopie scheidet wegen der höchstwahrscheinlich dann gestörten Referenzzählung dann auch aus.

Die Klasse, die die Formateinstellungen bereitstellt, sieht nun so aus:

markieren

Code:

class...
{
  TFormatSettings m_FormatSettings;
...
  TFormatSettings* GetFormatSettings() {return &m_FormatSettings;};
};

GetFormatSettings() ist Funktion einer implementierten Schnittstelle und deshalb kein __property .

m_FormatSettings wird beim Erzeugen der Instanz wie benötigt gefüllt und danach nicht mehr verändert.