Artikel und Bibliothek zu Serialisierung

Sehr gerne :) Wenn du das in einem Projekt nutzt oder 
Verbesserungsvorschläge oder Fehler gefunden hast würde ich mich über 
Rückmeldungen freuen...

Angenommen man hat eine Pointer-Cast-Variante dieser Art:

1

typedef struct {

2

  uint8_t A;

3

  uint16_t B;

4

} DataPacket;

5

6

DataPacket* deserialize (const uint8_t* raw) {

7

  return (DataPacket*) raw;

8

}

9

10

int main () {

11

  const uint8_t raw [100];

12

  fread (raw, ...);

13

  DataPacket* dp = deserialize (raw+1); // 1. Byte überspringen

14

  printf ("%" PRIu16, dp->B);

15

}

Dann ist der Lesezugriff auf B ggf. unaligned und führt zu undefined 
behaviour. Man muss genau darauf achten dass der umgecastete Pointer 
korrektes Alignment hat; memcpy() vermeidet das komplett. Würde man z.B. 
uint16_t statt uint8_t nutzen weil man ein Interface hat das immer 
16bits auf einmal überträgt, verletzt das außerdem die strict aliasing 
regel, ist dann also undefined behaviour egal ob korrektes alignment 
oder nicht.

Eine 100% konforme memcpy()-Implementation castet auf einen char-Typ und 
kopiert char-weise, so wie der else-Zweig in deinem Code. Konkrete 
Implementationen der C Standard Library können das optimieren wie im 
if-Zweig, aber das ist dann eben nicht portabel und eben für die eine 
Plattform der C-Library spezifisch. Tatsächlich ist dieser Code dem 
Standard nach sogar falsch, denn er verletzt die strict aliasing Regel - 
mit etwas Pech könnte der Compiler ihn kaputt optimieren. Daher sollte 
man so etwas im user code lieber nicht machen.

Gerne... ich hoffe es ist hilfreich :)

Super Artikel, vielen Dank. Denke, das klärt für viele Leute einiges 
auf. Planst du, die Lib auch für Floating Point zu implementieren?

Danke :) Floating-Point-Unterstützung plane ich derzeit nicht, weil das 
ziemlich kompliziert wäre. Wenn du eine portable Routine hast, die float 
<-> uint8_t[4] o.ä. konvertiert, kann ich die natürlich sehr gerne 
einbauen.
Da ja der C++-Standard kein bestimmtes Float-Format vorschreibt, man in 
den serialisierten Daten aber vermutlich IEEE 754 haben möchte, müsste 
man mithilfe der Standard Floating-Point-Funktionen (frexp & Co) die 
floats auseinandernehmen und daraus IEE754-Floats konstruieren. Die 
Frage ist dann auch, ob der Compiler das wegoptimiert falls die 
Plattform doch IEE754 nutzt...

Du meinst, das "rohe" Byte-Array und das Objekt per "union" auf den 
selben Speicherbereich legen? Das ist i.A. kaum machbar, da beide 
Repräsentationen unterschiedlich groß sein können, sich dies auch bei 
den einzelnen Elementen unterscheiden kann und man daher später 
benötigte Eingabedaten überschreiben würde.

GEKU schrieb:
> In der anderen Richtung sollte es funktionieren.

Ja, mit memmove()...  Aber Quelle und Ziel bestehen aus "char", welche 
immer gleich groß sind. Beim (De)serialisieren einer beliebigen 
Datenstruktur können die Größen der Datenelemente auf beiden Seiten 
prinzipiell beliebig unterschiedlich sein, es wird Padding eingefügt und 
Integer-Größen aufgerundet. Es kann immer irgendeine komplizierte 
Überlappung geben, sodass einfach nur rückwärts übertragen nicht reicht. 
Zudem war eigentlich das Ziel, zumindest auf die "raw" Daten immer 
vorwärts ("streng monoton") zuzugreifen, damit die einzelnen Elemente 
immer direkt ein/aus-gegeben werden können.

GEKU schrieb:
> Danke, es gibt für alles ein Lösung!

Hm, wo ist jetzt der Zusammenhang zu Thread/Artikel/Library?