Kann man einen Record in einem String speichern?

[QuickAndDirty]

Es geht um eine FMX App.
Kann man einen Record in einem String speichern und wenn ja wie?
Es sind ja beides Managed types die sich selbst freigeben und mit Copy on Write arbeiten.
Es geht mir darum einen Record in eine der TAG Variablen Von TListboxItem von FMX speichern.

Tag ist vom Typ NativeInt
TagString ist vom Typ String
TagObject ist vom Typ TObject
TagFloat ist vom Typ Float

Kann ich sowas wie

Delphi-Quellcode:

TagString[-2] := @MyRecord;

oder so machen?

[Der schöne Günther]

Der Benutzername ist Programm 😁

Ich würde mir mal das Speicherlayout von Records und Strings anschauen, ob dort die Referenzzähler an der gleichen Stelle sitzen.

[Rollo62]

Vielleicht so ?
http://francois-piette.blogspot.com/...rd-tofrom.html

Ich würde mir aber die JsonSerializer und verschiedenen Libraries dazu mal ansehen,
statt String direkt in einen modernen JsonString.
https://grijjy.github.io/GrijjyFound...alization.html

[Incocnito]

Ich packe immer alles in ein Objekt rein, was nicht bei drei auf den Bäumen ist. *hehe*

[Stevie]

Zitat:

Zitat von QuickAndDirty (Beitrag 1496967)

Es sind ja beides Managed types die sich selbst freigeben und mit Copy on Write arbeiten.

Wie bitte? Nur strings haben CoW.

[himitsu]

Ja, nur LongStrings.

dynamische Arrays nicht.

Intern ist ein LongString (AnsiString/UnicodeString) zwar auch nur fast ein "dynamisches" Array, aber leider kann man Copy-On-Write nicht für andere Array-Typen aktivieren. :cry:

Delphi-Quellcode:

A := B;  // nur Referenzzähler erhöhen
A[0] := 123;  // nur bei String wird vorher automatisch ein Unique ausgeführt ... bei anderen Arrays änders du den Wert in Beiden

// außer
A := Copy(B);  // wirklich kopieren
A[0] := 123;  // ändert nur A

[QuickAndDirty]

Zitat:

Zitat von Der schöne Günther (Beitrag 1496970)

Der Benutzername ist Programm ��

Ja ich versuche coolen code vom Stigma zu befreien er sei schlechter als coole Datenstructuren.

Zitat:

Zitat von Der schöne Günther (Beitrag 1496970)

Ich würde mir mal das Speicherlayout von Records und Strings anschauen, ob dort die Referenzzähler an der gleichen Stelle sitzen.

Meinst Emba hat verschiedene ARC systeme ? Eins für Records , ein anderes für LongStrings und ein drittes für Dyn-Arrays?

Zitat:

Zitat von Rollo62 (Beitrag 1496974)

Vielleicht so ?
http://francois-piette.blogspot.com/...rd-tofrom.html

Ich würde mir aber die JsonSerializer und verschiedenen Libraries dazu mal ansehen,
statt String direkt in einen modernen JsonString.
https://grijjy.github.io/GrijjyFound...alization.html

Sorry es geht mir nicht ums serialisieren. Ich möchte einfach nur an ein FMX Objekt (TListBoxItem ) einen Record anhängen. So wie man auch Integers, floats, Objects und Strings an ein TListBoxItem anhängen kann. Nach Möglichkeit so, dass der Refcount mitspielt.

Zitat:

Zitat von Incocnito (Beitrag 1496993)

Ich packe immer alles in ein Objekt rein, was nicht bei drei auf den Bäumen ist. *hehe*

Ich bin für viele Dinge zu Daten-Records in TArrays<Datenrecord> übergegangen. Vor allem weil man sowas auch mal als Rückgabe Wert haben kann ohne Bauchschmerzen zu bekommen was das Zerstören der Objekte angeht.

Zitat:

Zitat von Stevie (Beitrag 1497031)

Zitat:

Zitat von QuickAndDirty (Beitrag 1496967)

Es sind ja beides Managed types die sich selbst freigeben und mit Copy on Write arbeiten.

Wie bitte? Nur strings haben CoW.

Wenn ich einen Record als Parameter einer Funktion übergebe und ihn in der Funktion nur lesend verwende, dann wird der doch wie ein VAR, IN oder CONST Parameter vom Compiler behandelt oder nicht?
Auf jedenfall ist für meinen Verwendungszewck vor allem ARC das wichtige Attribut. CoW wäre aber schon nice to have.

Zitat:

Zitat von himitsu (Beitrag 1497032)

Ja, nur LongStrings.

dynamische Arrays nicht.

Intern ist ein LongString (AnsiString/UnicodeString) zwar auch nur fast ein "dynamisches" Array, aber leider kann man Copy-On-Write nicht für andere Array-Typen aktivieren. :cry:

Delphi-Quellcode:

A := B;  // nur Referenzzähler erhöhen
A[0] := 123;  // nur bei String wird vorher automatisch ein Unique ausgeführt ... bei anderen Arrays änders du den Wert in Beiden

// außer
A := Copy(B);  // wirklich kopieren
A[0] := 123;  // ändert nur A

Es geht ja um records also haben Records genug mit String oder TObject gemein das ich sie als TagString oder TagObject speichern kann und die Refcount Mechanik erhalten bleibt?

[himitsu]

hmmmmm .... nein .... joar

Wenn in dem Record irgendwas Zeigerartiges oder was mit Speicherautomatik drin steht,
dann kann darf das schonmal nicht biniär in einen anderen Speicher kopiert werden, unter Missachtung der Speichermechianissmen.
Außerdem muß man bei Binär aufpassen, dass einem die Stringbehandlung nicht die Daten schrottet. (z.B. bei konvertierung zwischen ANSI und Unicode)

Eine Konvertierung in ein Textformat (JSON, XML usw.) beseitigt all diese Fallstricke.

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1497049)

Eine Konvertierung in ein Textformat (JSON, XML usw.) beseitigt all diese Fallstricke.

:(
Aber das ist doch sooo meta.

Naja.
Wenigstens habe ich jetzt Klarheit.

[himitsu]

Ich und auch zuviele Andere hatten früher auch öfters mal Binärzeugs in String (AnsiString) und nun rate mal was dann im Jahr 2009 passierte. :stupid:

[Sinspin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1497052)

:(
Aber das ist doch sooo meta.

Das dachte ich mir auch lange Zeit. Alles kurz und knapp in records gepackt und in Dateien geschrieben oder durch die Gegend kopiert.
Mittlerweile verschicke ich so oft Daten über Netzwerk oder Pipes das ich ohne irgend einen standartisierten Container verzweifeln würde.
JSON ist nicht ganz meins. Ich verwende eine Komponente die auf eine Memtable aufsetzt.
Die Komponente kann man als Zeiger anhängen oder übergeben. Strings oder Dynarray verwende ich zum Transport, erzeugen und intepretieren macht die Komponente selber. Klappt wunderbar.

[Rollo62]

Zitat:

Zitat von Sinspin (Beitrag 1497070)

JSON ist nicht ganz meins.

Ja OK, es hat aber den Vorteil das es die ganze Welt draussen verstehen kann.
Ist ein einfacher String, kann alles Mögliche packen, und ist dabei relativ flott.

Für alle einigermaßen normalen Anwendungsfälle würde ich das schon als erste Wahl in Betracht ziehen,
oder man baut sich halt was Eigenes was hier und da mal klemmt und womöglich nur einen Bruchteil der Möglichkeiten hat.

Und für die Binärfans gibt es ja noch BSON :-)

[himitsu]

Auch XML gibt es in binär oder zumindestens "komprimiert" (gleiche "Wörter", wie z.B. Namen der Nodes und Attribute werden zusammengefasst) ... hat sich nur nicht so richtig durchgesetzt ... ist halt nicht menschenlesbar.

[KodeZwerg]

Etwas weit hergeholt aber vielleicht dennoch brauchbar? (da ich gerade nicht genau weiß wo du da was wie verdrahten wolltest)

Dein Record/Object im Speicher komprimieren (per ZLib als Beispiel), diesen Stream per Base64 in einen String wandeln, an dein ListItem ranheften, bei abruf auf umgekehrten weg zurück.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1497109)

Auch XML gibt es in binär oder zumindestens "komprimiert" (gleiche "Wörter", wie z.B. Namen der Nodes und Attribute werden zusammengefasst) ... hat sich nur nicht so richtig durchgesetzt ... ist halt nicht menschenlesbar.

Ja richtig, JSON hat XML meiner Meinung nach abgelöst, weil es das Gleiche kann, aber kleiner und besser lesbarer ist.
Vielleicht gibt es eine Erhebung wieviel JSON/XML genutzt wird.
Ich vermute insbesondere im Web gibt es fast 95% JSON zum Datenaustausch, und kaum XML,
nur auf Desktop wird XML wohl noch öfters benutzt, auch als Dokumentenformate.

[himitsu]

Das Gleiche nicht ganz.
XML kann man anders verschachteln, z.B. Attribute und SubNodes zusammen im Node.
Und dadurch, dass vieles Doppelt vorkommt (schließender Node), ist hier die Fehlerbereinigung etwas einfacher möglich.
(nja, wie an den Heuristiken für HTML vs. XHTML in vielen Browsern geht's so lala)

Es gibt auch JSON-artig verschachteltes INI-artiges (INI selber hat ja praktisch keine Standards),
welche für manuelle Änderungen einfacher sind,
nur mit dem Nachteil, wie in Python, also die Gruppen haben kein Ende, allerdings wird mit unsichtbaren Zeichen (Einzückung) gearbeitet,
aber dafür raucht nicht gleich alles komplett ab, wenn in einer/mehreren Zeile(n) ein Syntaxfehler*innen steckt.



Wenn es nur um die Größe ginge (OK, ein gzip/ZLib drüber macht auch alles nochmal kleiner),
dann dürfte das binäre XML womöglich kleiner sein, als BSON.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1497133)

Das Gleiche nicht ganz.

Ja sicher, Du weisst schon was ich meine :stupid:
XML wird gerne bei .docx und Adobe benutzt, aber das ist dann schon mehr als nur ein einfacher Datenaustausch.

Ich sehe JSON mittlerweile als Default-Austauschformat for "normale" Zwecke,
so wie früher die INI-Datei.

[Frickler]

XML kann über Schema automatisiert validiert werden. Die nötigen Programme sind seit vielen Jahren standardisiert. Und sowas wie XSLT und XSL-FO fehlt auch unter JSON. man ist zwar dabei, das hier und da nachzurüsten, hat damit aber keine Eile. Denn JSON ist ein Format für Datenübertragung, nicht so sehr für Dateien.

Hingegen sehe ich als "Nachfolger" der INI Datei heute eher SQLite.

[Rollo62]

Zitat:

Zitat von Frickler (Beitrag 1497147)

Hingegen sehe ich als "Nachfolger" der INI Datei heute eher SQLite.

:thumb:

[himitsu]

So lange das Ding dann nicht auch mal schnell ohne Hilfsmittel per Hand bearbeitet werden soll. :stupid:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1497167)

So lange das Ding dann nicht auch mal schnell ohne Hilfsmittel per Hand bearbeitet werden soll. :stupid:

Genau da sehe ich auch einen gravierenden Nachteil. INI-Datei (und natürlich jedes andere textbasierte Format) oder Registry lassen sich auf jedem Windows am Einsatzort mit Bordmitteln bearbeiten. Ein Programm zum Manipulieren einer SQLite DB darf ich dort vielleicht gar nicht mal installieren.

[himitsu]

Dafür gibt es zum Glück wenigstens noch eine portable 1-EXE-Variante, aber die muß man dann erstmal mithaben.
OK, draufkopieren und starten muß man sie auch noch dürfen.

[Sinspin]

Zitat:

Zitat von Rollo62 (Beitrag 1497090)

Zitat:

Zitat von Sinspin (Beitrag 1497070)

JSON ist nicht ganz meins.

Ja OK, es hat aber den Vorteil das es die ganze Welt draussen verstehen kann.
Ist ein einfacher String, kann alles Mögliche packen, und ist dabei relativ flott.

Es geht mir nicht darum wie flott es ist. Genau wie XML ohne Schema ist JSON ohne Schema dumm! Wer es lesen will muss die Struktur kennen und die Datentypen der Felder.
Klar, wenn man Daten sendet oder empfängt ist eigentlich immer bekannt was für ein Typ auf welchem Feld steht. Aber warum soll ich im Quelltext, jedesmal wenn ich zugreife die Konvertierung selber machen und sicherstellen dass das Datenformat passt? Klassen für JSON schaffen da ein wenig Abhilfe, aber es bleibt bis zum letzten Wert die Ungewissheit das man auch das findet was man erwartet.
Leider ist das Schema bei JSON nicht verpflichtend anzugeben, ich habe auch noch keine Daten gesehen die es verwendet hätten.
Somit ist mir persönlich etwas lieber was automatisch sein Datenformat mit dabei hat.