Vielleicht mögen die Fragen ein wenig blöd klingen allerdings beschäftigt mich das jetzt schon ein paar Tage.

[1]
Folgendes Szenario: Es liegt ein eigenes Dateiformat vor:

template<class CharType>
struct FILE_HEADER
{
    CharType  m_Signature[20];
    int       m_Value1;
    int       m_Value2;
    CharType  m_Data[100];
    size_t    m_DataLen;
};

Oben soll also beispielsweise ein Header für das Dateiformat gegeben sein.
Ich speichere und lese ihn wie folgt aus einer Datei:

template <class CharType>
void Write(const CharType *pFileName)
{
    FILE_HEADER Hdr;
    std::ofstream file(pFileName);
    CharType *pOut = new CharType[sizeof(FILE_HEADER)];   

    // Header mit Daten füllen
    FillHeader(&Hdr);

    // Struktur in Puffer kopieren
    memcpy(pOut, &Hdr, sizeof(FILE_HEADER));

    // Speichern
    file.write(pOut, sizeof(FILE_HEADER));

    delete [] pOut;

    file.close();    
} 

template <class CharType>
void Reade(const CharType *pFileName, FILE_HEADER &Hdr)
{
    std::ofstream file(pFileName);
    CharType *pIn = new CharType[sizeof(FILE_HEADER)];   

    // Lesen
    file.read(pIn, sizeof(FILE_HEADER));

    // Puffer in Struktur kopieren
    memcpy(&Hdr, pIn, sizeof(FILE_HEADER));

    delete [] pIn;

    file.close();    
}

Kann hier mit dem memcpy irgendwas schiefgehen, also das nicht alle Daten der Struktur oder aus der gelesenen Datei erwischt werden? Ich meine keine Lese-/Schreibfehler.

Hier habe ich auch noch eine Frage zu "#pragma pack". Bezieht sich auf MS Compiler. Ich verstehe aus der MSDN Beschreibung nicht ganz was #pragma pack bewirkt. Es nimmt Einfluss darauf wie die Daten im Speicher liegen. Was heißt das genau und müsste ich ich hier vor meine FILE_HEADER Struktur ein #pragma pack(1) und am Ende wieder ein #pragma pack() setzen?

[2]
Es sollen meherer Strings inkl. ihrer Längen kopiert werden und in einen anderen String kopiert werden, welcher dann verschlüsselt wird und ebenfalls in die Datei geschrieben wird.

template<class CharType>
void SaveStrings(const std::basic_string<CharType> &s1, const std::basic_string<CharType> &s2, const std::basic_string<CharType> &s3)
{
    CharType *pOut   = 0;
    size_t    OutLen = sizeof(size_t) * 3 + // 3 Längenangaben der Strings
                       s1.size() + s2.size() + s3.size();
    size_t    Pos    = 0;

    Chartype pOut = new CharType[OutLen];

    memcpy(&s1.size(), pOut, sizeof(size_t));
    Pos += sizeof(size_t);

    memcpy(&s2.size(), pOut + Pos, sizeof(size_t));
    Pos += sizeof(size_t);

    memcpy(&s3.size(), pOut + Pos, sizeof(size_t));
    Pos += sizeof(size_t);

    memcpy(s1.c_str(), pOut + Pos, s1.size());
    Pos += s1.size();

    memcpy(s2.c_str(), pOut + Pos, s2.size());
    Pos += s2.size();

    memcpy(s3.c_str(), pOut + Pos, s3.size());

    // Verschlüsseln und Speichern

    delete [] pOut;
}

Das Laden des String erfolgt ähnlich. Auslesen, Entschlüsseln String kopieren:

size_t size = 0;

    // Längen auslesen
    memcpy(pIn, &size, sizeof(size_t));

Mit memcpy sollte auch hier doch nichts schiefgehen, da doch nur die Bytes kopiert werden, oder müsste man die Längenangaben extra per Bitoperationen in einen CharType wandeln wie hier zu sehen

void ulong_to_uchar (unsigned char pBuf[4], const unsigned long &val)
{
    pBuf[0] = static_cast<unsigned char>( ( vVal  >> 24 )  & 0xff );
    pBuf[1] = static_cast<unsigned char>( ( val  >> 16 )  & 0xff );
    pBuf[2] = static_cast<unsigned char>( ( val  >>  8 )  & 0xff );
    pBuf[3] = static_cast<unsigned char>(   val           & 0xff );
}

und dann diesen char ein den String kopieren? An sich müsste es doch memcpy egal sein was für Daten es kopiert. Hauptsache keine Pufferüberläufe.

Hoffe es ist halbwegs zu verstehen was ich wissen möchte.

Deine Version von ulong_to_uchar ist plattform bzw little-big-endian unabhängig also "besser" als memcopy aber langsamer(falls du es sehrsehrsehr oft aufrufst)

@1b: "#pragma pack()" gibt an, wie die Strukturelemente im Speicher ausgerichtet werden. Je nach Einstellung (und Größe der Member) können noch Füll-Bytes dazwischengeschoben werden, um die Adressen zu korrigieren. Das wird nur dann problematisch, wenn du die Daten zwischen verschiedenen Systemen austauschen willst.

@2: Wenn alle Teile des Programms vom selben Compiler stammen, passt auch die Bitlage deiner Zahlenwerte zusammen. Wenn du auf diesem Weg Daten zwischen verschiedenen Systemen austauschen willst, ist die Anpassung über Bit-Operationen sicherer (btw, das gilt auch für die int-Anteile aus Teil [1]).

Teilantworten:
Also bei Deiner Datenstruktur sollte pack(1) keinen Einfluss habe, da Deine Addressen alle durch 4 (defaultwert) teilbar sind.
Generell muss pack beim schreiben und lesen einfach gleich sein.

Also das alles durch 4 teilbar ist, ist glaube ich Zufall. Würde folgende abgeänderte Struktur an Funktionalität etwas ändern?

template<class CharType>
struct FILE_HEADER
{
    CharType  m_Signature[23]; // vorher 20
    int       m_Value1;
    int       m_Value2;
    CharType  m_Data[111]; // vorher 100
    size_t    m_DataLen;
};

templäd schrieb:

Deine Version von ulong_to_uchar ist plattform bzw little-big-endian unabhängig also "besser" als memcopy aber langsamer(falls du es sehrsehrsehr oft aufrufst)

Also entnehme ich darus das es in meinem Fall egal ist. Die Software soll nur unter Windows laufen auf Intel- bzw. IBM kompatiblen Systemen.

CStoll schrieb:

@1: memcpy() kopiert byteweise den kompletten Speicherbereich - da du keine "externen" Daten verwendest, ist das hier völlig ausreichend (aber unnötig - du kannst auch read()/write() direkt auf deine FILE_HEADER loslassen).

Müsste dann nur in CharType casten also

std::basic_fstream<CharType> file("Dateiname");

file.write(reinterpret_cast<CharType*>(&Header), sizeof(FILE_HEADER<CharType>));

Wäre um einiges performater, da ich eine Speicheranforderung weglassen kann.

CStoll schrieb:

@1b: "#pragma pack()" gibt an, wie die Strukturelemente im Speicher ausgerichtet werden. Je nach Einstellung (und Größe der Member) können noch Füll-Bytes dazwischengeschoben werden, um die Adressen zu korrigieren. Das wird nur dann problematisch, wenn du die Daten zwischen verschiedenen Systemen austauschen willst.

Wie oben erwähnt. Die Software soll nur unter Windowssystemen laufen. Hättest du vielleicht ein Beispiel wo #pragma pack(xyz) genutzt werden müsste?

CStoll schrieb:

@2: Wenn alle Teile des Programms vom selben Compiler stammen, passt auch die Bitlage deiner Zahlenwerte zusammen. Wenn du auf diesem Weg Daten zwischen verschiedenen Systemen austauschen willst, ist die Anpassung über Bit-Operationen sicherer (btw, das gilt auch für die int-Anteile aus Teil [1]).

Also kein Problem solange es unter Windowssystemen läuft. Wenn es jetzt aber z.B. unter einem PowerPC wo Windows in einer VM läuft, würde es schiefgehen, richtig?

Also kein Problem solange es unter Windowssystemen läuft. Wenn es jetzt aber z.B. unter einem PowerPC wo Windows in einer VM läuft, würde es schiefgehen, richtig?

ne VM sollte tunlichst das windows bit-ordering emulieren, sonst wärs keine anständige VM. probleme bekommst dann, wenn dein programm nativ auf anderen system laufen soll.

ne VM sollte tunlichst das windows bit-ordering emulieren, sonst wärs keine anständige VM. probleme bekommst dann, wenn dein programm nativ auf anderen system laufen soll.

Stimmt. Im Nachhinein wohl schwachsinn. Danke.

CStoll schrieb:

@1: memcpy() kopiert byteweise den kompletten Speicherbereich - da du keine "externen" Daten verwendest, ist das hier völlig ausreichend (aber unnötig - du kannst auch read()/write() direkt auf deine FILE_HEADER loslassen).

Müsste dann nur in CharType casten also

std::basic_fstream<CharType> file("Dateiname");

file.write(reinterpret_cast<CharType*>(&Header), sizeof(FILE_HEADER<CharType>));

Wäre um einiges performater, da ich eine Speicheranforderung weglassen kann.

Ja, genau so sollte es funktionieren (abgesehen von der Tatsache, daß FILE_HEADER kein Template ist ;)).

CStoll schrieb:

@1b: "#pragma pack()" gibt an, wie die Strukturelemente im Speicher ausgerichtet werden. Je nach Einstellung (und Größe der Member) können noch Füll-Bytes dazwischengeschoben werden, um die Adressen zu korrigieren. Das wird nur dann problematisch, wenn du die Daten zwischen verschiedenen Systemen austauschen willst.

Wie oben erwähnt. Die Software soll nur unter Windowssystemen laufen. Hättest du vielleicht ein Beispiel wo #pragma pack(xyz) genutzt werden müsste?

Auf Anhieb nicht. Solche Anpassungen brauchst du vor allem, wenn du ein bestimmtes Speicher-Layout erzwingen willst. Bei deiner geänderten Struktur könnten z.B. nach den beiden char-Arrays padding-Bytes eingefügt werden, die (a) eventuell unnötigen Speicherplatz verbrauchen und (b) das Layout durcheinanderwürfeln können.

Ja, genau so sollte es funktionieren (abgesehen von der Tatsache, daß FILE_HEADER kein Template ist ;)).

Doch, FILE_HEADER ist doch ein Template.

template<class CharType>struct FILE_HEADER { /* ... */ };

CStoll schrieb:

Auf Anhieb nicht. Solche Anpassungen brauchst du vor allem, wenn du ein bestimmtes Speicher-Layout erzwingen willst. Bei deiner geänderten Struktur könnten z.B. nach den beiden char-Arrays padding-Bytes eingefügt werden, die (a) eventuell unnötigen Speicherplatz verbrauchen und (b) das Layout durcheinanderwürfeln können.

Schade. Falls dir noch mal eines über den Weg läuft, wäre ich dran interessiert. Also sollte es auch noch mit der geänderten Sruktur, wo nicht mehr alle Memeber durch 4 teilbar sind klappen.

CStoll schrieb:

Ja, genau so sollte es funktionieren (abgesehen von der Tatsache, daß FILE_HEADER kein Template ist ;)).

Doch, FILE_HEADER ist doch ein Template.

template<class CharType>struct FILE_HEADER { /* ... */ };

Ups, stimmt. Das hatte ich übersehen.

CStoll schrieb:

Auf Anhieb nicht. Solche Anpassungen brauchst du vor allem, wenn du ein bestimmtes Speicher-Layout erzwingen willst. Bei deiner geänderten Struktur könnten z.B. nach den beiden char-Arrays padding-Bytes eingefügt werden, die (a) eventuell unnötigen Speicherplatz verbrauchen und (b) das Layout durcheinanderwürfeln können.

Schade. Falls dir noch mal eines über den Weg läuft, wäre ich dran interessiert. Also sollte es auch noch mit der geänderten Sruktur, wo nicht mehr alle Memeber durch 4 teilbar sind klappen.

Theoretisch ja, praktisch müsstest du mal sehen, ob dich die Padding-Bytes im Ernstfall stören.

PS: Laut meiner MSDN ist der Defaultwert für's Padding bei 8, also hast du auch in der Originalversion möglicherweise schon Lücken im Objekt.

Theoretisch ja, praktisch müsstest du mal sehen, ob dich die Padding-Bytes im Ernstfall stören.

Also. Ich habe mal Testweise die Struktur mit Zufallswerten gefüllt in einer Schleife in die Datei schreiben lassen und wieder auslesen lassen. Dann mit memcmp die Bytes verglichen und es haut alles hin. Das ist die Struktur

template<class CharType>
    struct MAIN_HEADER
    {
        CharType             m_pSignature[7];
        short                m_MajorVersion;
        short                m_MinorVersion;
        EncryptionAlgorithm  m_EncryptionAlgorithm;
        CharType             m_pSalt[32];
        int                  m_Counter;
        CharType             m_pReserved[54];
    };

Die "echte" Größe der Struktur ist 105 Bytes. Ohne #pragma pack Angaben - Standardwert 8 - ist die Struktur allerdings 108 Bytes groß. Also wird etwas aufgefüllt. Das mit dem Padding verstehe ich nicht ganz in der MSDN. Wozu dient das?
Es läuft in meinem Test auch alles mit #pragma pack(1). Hier hat die Struktur dann ihre Originalgröße von 105 Bytes.

Eine Sache verunsichert mich hier allerdings:

MSDN schrieb:

Note that if you change the alignment of a structure, the structure will not use as much space in memory, but you may see a decrease in performance or even get a hardware-generated exception for unaligned access. It is possible to modify this exception behavior with SetErrorMode.

Ja, habe ich denn jetzt ein Performanzverlust bei #pragma pack(1)?

CStoll schrieb:

PS: Laut meiner MSDN ist der Defaultwert für's Padding bei 8, also hast du auch in der Originalversion möglicherweise schon Lücken im Objekt.

Klingt nett. Ich habe auch eine.

struct test
{
  char c;
  int i;
};

Die Verbindung zwischen Prozessor und Speicher kann heute meist 4 Byte auf einmal übertragen, also ist es günstig, wenn der int-Wert an einer Adresse steht, die durch 4 teilbar ist. da der char nur 1 Byte benötigt, wird das erreicht, indem noch 3 Füllbytes dazwischengeschoben werden (welchen Wert die haben, ist nicht festgelegt^*) - damit hat die gesamte Struktur eine Größe von 8 Byte (c(1)+3+4(i)).

Wenn du das Padding ausschaltest, werden alle Elemente lückenlos hintereinander untergebracht, dadurch reduziert sich die Größe auf 5. Allerdings liegt der int jetzt nicht mehr geeignet im Speicher, um auf einen Schlag ausgelesen zu werden - also muß das Programm für einen Zugriff erst zwei 4-Byte-Blöcke lesen und daraus den int-Wert zusammenbauen (und in der anderen Richtung ihn wieder zerlegen und in Einzelteilen zurückschreiben).

^* das bedeutet auch, daß du mitunter falsche Antworten erhältst, wenn du eine Struktur elementweise kopierst und dann per memcmp() vergleichst:

test t1 = {'a',4711},t2;
t2.c=t1.c;t2.i=t1.i;
cout<<(memcmp(t1,t2)==0)?"gleich":"verschieden";//was hier ausgegeben wird, hängt von den willkürlichen Werten der Padding-Bytes ab

OK, dann etwas ausführlicher: Das Padding dient dazu, die Position einzelner Member an "gutartigen" Speicheradressen auszurichten. Nehmen wir also eine etwas einfachere Struktur:

struct test
{
  char c;
  int i;
};

Die Verbindung zwischen Prozessor und Speicher kann heute meist 4 Byte auf einmal übertragen, also ist es günstig, wenn der int-Wert an einer Adresse steht, die durch 4 teilbar ist. da der char nur 1 Byte benötigt, wird das erreicht, indem noch 3 Füllbytes dazwischengeschoben werden (welchen Wert die haben, ist nicht festgelegt^*) - damit hat die gesamte Struktur eine Größe von 8 Byte (c(1)+3+4(i)).

Wenn du das Padding ausschaltest, werden alle Elemente lückenlos hintereinander untergebracht, dadurch reduziert sich die Größe auf 5. Allerdings liegt der int jetzt nicht mehr geeignet im Speicher, um auf einen Schlag ausgelesen zu werden - also muß das Programm für einen Zugriff erst zwei 4-Byte-Blöcke lesen und daraus den int-Wert zusammenbauen (und in der anderen Richtung ihn wieder zerlegen und in Einzelteilen zurückschreiben).

Wunderbar. Herzlichen Dank.

CStoll schrieb:

^* das bedeutet auch, daß du mitunter falsche Antworten erhältst, wenn du eine Struktur elementweise kopierst und dann per memcmp() vergleichst:

test t1 = {'a',4711},t2;
t2.c=t1.c;t2.i=t1.i;
cout<<(memcmp(t1,t2)==0)?"gleich":"verschieden";//was hier ausgegeben wird, hängt von den willkürlichen Werten der Padding-Bytes ab

Das heißt ich könnte mit meinen efrigen memcmp Vergleichen bei allen zig Testdurchläufen immer Glück gehabt haben und sollte lieber jeden Member einzeln vergleichen.

P.S.: Vor jedem Schreiben eines Header wird dieser intialisiert mit

memset(&Header, 0x00, sizeof(MAIN_HEADER))

. Das erwischt doch auch die Paddingbytes, sodass memcmp wiederum nicht glücklich verlief sondern "korrekt", oder?

(und bei deinem Ansatz oben (Daten schreiben, wieder einlesen und dann vergleichen) kommt auch aus Prinzip das richtige Ergebnis heraus, weil read() und write() ebenfalls alles ohne Rücksicht auf die interne Struktur lesen bzw. schreiben)

PS: Problematisch wird es, wenn du zwischen schreiben und lesen das Layout der Struktur geändert hast, d.h. wenn du z.B. einen Header schreibst, dann im Programm die Padding-Einstellungen änderst und mit der neuen Version diesen Header wieder auszulesen versuchst - dabei stimmen die Daten immer noch auf Byte-Ebene überein, aber die einzelnen Bytes gehören nicht mehr zu den selben Membern. Zum Beispiel bei meiner obigen test-Struktur:

//Lauf 1 mit Standard-Padding:
test t = {'a',4711};
file.write((char*)&t,sizeof(test);
//Ergebnis: 61 xx xx xx 00 00 12 67

//Lauf 2 compiliert mit #pragma pack(1)
test t;
file.read((char*)&t,sizeof(test);
//Ergebnis: 61 xx xx xx 00
//in t.i kann jetzt alles mögliche drin stehen, aber bestimmt nicht 4711

PS: Problematisch wird es, wenn du zwischen schreiben und lesen das Layout der Struktur geändert hast, d.h. wenn du z.B. einen Header schreibst, dann im Programm die Padding-Einstellungen änderst und mit der neuen Version diesen Header wieder auszulesen versuchst - dabei stimmen die Daten immer noch auf Byte-Ebene überein, aber die einzelnen Bytes gehören nicht mehr zu den selben Membern. Zum Beispiel bei meiner obigen test-Struktur:

//Lauf 1 mit Standard-Padding:
test t = {'a',4711};
file.write((char*)&t,sizeof(test);
//Ergebnis: 61 xx xx xx 00 00 12 67

//Lauf 2 compiliert mit #pragma pack(1)
test t;
file.read((char*)&t,sizeof(test);
//Ergebnis: 61 xx xx xx 00
//in t.i kann jetzt alles mögliche drin stehen, aber bestimmt nicht 4711

Das sollte nicht passieren. Werde es einfach ohne eine #pragma pack Anweisung machen, da sie ja hier nicht nötig ist. Vielen Dank auch.