Kann man einen Record in einem String speichern?

[QuickAndDirty]

Zitat von Der schöne Günther:

Der Benutzername ist Programm ��

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

Zitat von Der schöne Günther:

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 von 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

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 von Incocnito:

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 von Stevie:

Zitat von QuickAndDirty:

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 von 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.

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 von himitsu:

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.

[Sinspin]

Zitat von QuickAndDirty:

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 von Sinspin:

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 von 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.

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.

[Sinspin]

Zitat von Rollo62:

Zitat von Sinspin:

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.