Teg wrote:
Hello pps,
I'd argue that serialization's basically the same as marshalling or
using CArchive to serialize in a windows environment. When you
serialize you're enforcing a standard for data packing and alignment
so, you're simply solving the problem in a different way. You're
throwing a layer over top of the whole problem that solves it for you.
I don't know anything about marshaling or CArchive - somebody mentioned
marshaling and I googled to see what was that.
About "a layer over top"... this layer is logical, the binary code at
the end might be almost identical.
for example, for struct X{ char a,b,c; }; it would be more efficient and
correct to use something like *p = x.a; *(++p) = x.b; *(++p) = x.c;
(where p is pointer to some char array), that memcpy(&x,sizeof(x)...
If you're not serializing and want to save a struct to a blob then you
run into both alignment and possibly structure packing problems (if
the program reading the database was compiled with either a different
compiler and/or has a different structure packing enforced). If you
think about it, if structure packing isn't the same, you can't really
use the "blob as struct" at all can you?
That's what I'm trying to tell here - simply casting objects to char
pointers and copying them to/from blobs is *not* correct way to do this
kind of thing; this data stored as blob may be accessed by a different
app that might have been compiled with different compiler settings for
struct member allignment (not to mention different compiler, or whatever).
Simply because it works for some people doesn't mean it will work for
others. After all, it's just horrible style to use memcopy in this case;
some extra code that puts byte after byte and at the same sequence reads
them back will assure correct behavior and will cost just a couple of
cpu cicles (compared to millions that any app usally waits for disk
data), or, in some cases, it could be more efficient than using memcopy!!
