Sorry, but that's just not going to happen.
If I see this advice again, I'll say something again. I'm not going to leave some poor newbie with bad information just because you are arrogant.
I'd hope you'd do me the same favor.
The `pragma' directive is compiler specific, and that particular one only controls packing. It doesn't effect endianness, the size of the data types, or the format of floating point data elements on platforms with multiple possibilities. Naturally, anyone with any sense would recommend using the standard size types. The combination of compiler specific directives with the portable standard sized types still only give you about one-fourth of the picture.
#pragma pack().... You have total control over that.
Unfortunately, what I've said about this situation is statements of fact. They are not opinion.
Really... you may be more experienced and smarter than me (at least you seem to think so) but about THIS, you are flat out wrong.
Here, instead of giving bad examples of why you think you are right; why not put you money where your mouth is and try an example, actually learn something, and be able to pass that along?
Now, compile on "MSVC2K3" for "Windows", "Intel C++ Compiler" for "Windows", "GCC" for "Windows", "GCC" for "GNU/Linux", and "Intel C++ Compiler" for "GNU/Linux".
// add packing prefix if you like
// typedef unsigned 8 bit int
// typedef unsigned 16 bit int
// typedef unsigned 32 bit int
// typedef signed 8 bit int
// typedef signed 16 bit int
// typedef signed 32 bit int
// typedef unsigned 8 bit int array of 8 elements
// typedef unsigned 16 bit int array of 8 elements
// typedef unsigned 32 bit int array of 8 elements
// typedef signed 8 bit int array of 8 elements
// typedef signed 16 bit int array of 8 elements
// typedef signed 32 bit int array of 8 elements
// ASCII string type 64 element array useful for standard string functions
// wide string type 64 element array useful for standard wide string functions
// typedef for whatever happens to be native floating point type 1
// typedef for whatever happens to be native floating point type 2
// typedef for whatever happens to be native floating point type 3
// add packing postfix if you like
// later in code
fread(/*the above structure */);
// print the above structures contents
// randomly mutate the above structures contents
fwrite(/* the above structure */);
Now compile again with whatever the given compilers variations are for optimize for speed, again for size, again with whatever holds for "fast math", and again for whatever holds for "use native floating point width".
Be amazed as you get about six different sizes and about twelve different binaries.
I sincerely hope you are joking, but just in case you are not, I'll give you an example of what a few "SQL" database engine providers applications do write from my time with them in years past.
And exactly what do you think data bases like sql write? Yep, records based storage...
"Oracle" serializes data as a collection of "B*Tree" suites with a variation on branching not normally seen in the wild with all the pointers having the same endianness which is a determined from a flag from earlier in a given database chunk (file). Different elemental "SQL" types can have different underlying representations depending on flags used when creating the database, but one commonality is length prefixed strings in trees created as part of an indexing operation for a given table.
"SQLite" serializes the possible 64 bit values of all of its native "SQL" integer types as well as indexes for internal use as a variation on a length prefix string targeting space optimization meaning that a seven bit value takes up a byte while a 64 bit value takes up nine bytes.
"MySQL" with some community patches for faster text searching in text fields using a generalization of the same algorithm "Firefox" uses for spell checking builds two index trees for an indexing operating on a table with a full text search field where on table is sorted on fixed length 64 bit integers representing "UNIQUE_KEY" and while the other uses variable length, length prefixed strings of the shortened word from the variation of the spell checking algorithm as keys.
Strangely enough, not one of these tools simply dumps the binary chunk the compiler hands them into a file.