Ich habe ein kleines Problem beim Nutzen von memcpy. Hier mal eine abgespeckte Form meines Programms:

struct HeadStruct
{
  long a;
  long b;
  long c;
  long d;
};

typedef struct HeadStruct HeadStruct;

struct MyStruct
{
  HeadStruct Head;
  long e;
  long f;
  long g;
};

typedef struct MyStruct MtSruct;

template <typename MyStruct>
class MyClass
{
  MyStruct MyStructInClass;
};

Ich will nun die Daten in einen char-Buffer kopieren (allerdings ohne Head):

MyClass<MyStruct> A;
char* Buffer;
// das jetzt klappt net...
memcpy(Buffer, &(A.MyStructInClass) + sizeof(HeadStruct), sizeof(A.MyStructInClass) - sizeof(HeadStruct));

und dann hab ich komischerweise die falschen Werte im Buffer...

Wollte noch ergaenzend sagen, dass die Werte dann ueber Netzwerk verschickt werden, und am anderen Ende wieder in die Klasse MyClass geladen werden. Und dann stimmen die Werte net...

Vlt kann ja jemand helfen

Warum nimmst Du nicht &(A.MyStructInClass.e)?

Achja: Für Buffer ist kein Speicher reserviert

ich würde das auch nicht so machen, sondern ein "anständiges" Übertragungsformat definieren und die Dateninhalte einzeln übertragen (wie bei Java in serialize()).
Damit bist Du auf jeden Fall unabhängiger und sicherer.
In C++ brauchst Du daraus nicht mal eine Klasse zu machen, denn structs fürfen auch Funktionen haben.

struct MyStruct
{
    HeadStruct Head;
    long e;
    long f;
    long g;
    void body2SendFormat(char* szBuffer, size_t BufferLen, size_t& outDataLen) 
    { // Was Du hier machst, ist egal, hauptsache umkehrbar .... 
    }
    void sendFormatBodyImport(char* szBuffer, size_t dataLen) { .... }
};

Natürlich kannst Du das Format auch außerhalb des Structs definieren (vA, wenn Du es noch für andere Datentypen verwenden willst...

Wenn Du es "ganz schick in C++" haben willst, kannst Du auch für Deinen Netzwerkstream <<- und >>-Operatoren überladen, die direkt Dein Struct übernehmen...

Ach ja: Über die "Lebenszeit" Deines Objekts musst Du Dir noch Gedanken machen !
In Deinem Beispiel wird das Objekt vorher erzeugt und die Werte (besonders Head...) belegt. Wenn Du ein echtes "Erzeugen aus den angelieferten Daten" umsetzen willst, solltest Du ein wenig unter "factory pattern" nachlesen.

Gruß,

Simon2.

Das die Variablen nicht initialisiert sind ist klar, wollt das alles ein bissl abspecken und net verwirren...sry.

Das Problem ist, dass die structs so (unschoen) generiert werden, und ich mit denen arbeiten muss...

Dadurch, dass ich eine struct in einer struct habe, gibt es Padding-Bytes, die sizeof nicht angibt, bei memcpy aber ueberschrieben werden. Und deshalb verschieben sich die Werte...

...stimmt das

struct HeadStruct
{
  long a;
  long b;
  long c;
  long d;
};

struct MyStruct
{
  HeadStruct Head;
  char dummy;
  long e;
  long f;
  long g;
};

template <typename MyStruct>
class MyClass
{
  MyStruct MyStructInClass;
};

MyClass<MyStruct> A;
char* Buffer;
char* pDummy = reinterpret_cast<char*>(&(A.MyStructInClass.dummy));
memcpy(Buffer, pDummy, sizeof(A.MyStructInClass) - (pDummy - reinterpret_cast<char*> (A.MyStructInClass)));

(Bin mir damit nicht ganz sicher). Besser wäre aber definitiv eine Serialisierung, wie Simon es vorschlug.

Wenn man den Compiler noch den Befehl /Zp1 (gibt es auch mit /Zp2, /Zp4, usw...), dann werden 1-Byte-Bounderies benutzt. Dadurch wird das padding vermieden, und alles ist im lot

Ok, here we go:

Wenn man den Compiler noch den Befehl /Zp1 (gibt es auch mit /Zp2, /Zp4, usw...), dann werden 1-Byte-Bounderies benutzt. Dadurch wird das padding vermieden, und alles ist im lot

Hi,

Du solltest aber nicht das Problem vergessen, dass dieser Weg unbrauchbar wird, z.B. weil
- mal ein anderer Compiler benutzt wird (oder die neue Compiler-Version diese Option anders/nicht mehr unterstützt),
- schreibender und lesender Code von unterschiedlichen Leuten (Gruppen, Firmen, ...) verfasst/gepflegt wird (die vllt. gar nicht diese Option nutzen können),
- Du nächstes Jahr vllt. eine Bibliothek (für etwas ganz anderes) verwenden sollst/musst, die sich mit dieser Compilereinstellung beisst,
- Bei der Analyse herauskommt, dass die Performance unszureichend ist und ein Alignment deutliche/notwendige Steigerungen auf der Plattform ergäbe,
- ....

Natürlich kann man das auch auf sich zukommen lassen ("Optimieren/Flexibilisieren erst dann, wenn die Notwendigkeit dazu besteht" ist ja auch ein sinnvoller Grundsatz), aber es hilft dann später sehr, wenn man es jetzt zumindestens gründlich dokumentiert.
Außerdem kommst Du damit später in "Migrationsprobleme" (was, wenn ClientSW oder Datenbestände mit dem alten Format bestehen, Du aber den Server auf das neue umstellen willst), die Du Dir jetzt evtl. sparen kannst...

Gruß,

Simon2.