Teg wrote:
Hello Nathan,
Depends on how you access them. Most RISC CPU's can't do unaligned access
to multi-byte values like int's and long, they'll segfault. Intel
CPU's don't have this problem. If you memcpy the values into place,
this is a non-issue. You see it alot with embedded CPU's.
Without knowing his environment, there's no way to guess how this
would shake out. It'll work as long as the structs don't have pointers
in them. That means anything other than naked structs won't work with
the blob technique (no strings or C++ classes). You know, there's a
whole process that I believe Microsoft calls marshalling which is used
to take structs of all sorts and send them over a wire and
re-constitute them on the other side. It's fairly complicated.
My guess is he wants to store two ints and we're getting way too
complicated but, that's just a guess.
In fact, it's very simple to have multibyte values to be put into blobs
(or, simply, some binary strings/buffers). IMHO, it's almost always a
very bad decision to use memcpy for a couple of ints (alignment &
padding problems for structs). Better, write some small functions that
print/read data to/from binary strings. What is more interesting is to
be able to store complex objects, where you have pointers to dynamically
allocated objects etc., that's where things get hairy...
I don't know about what's microsoft's marshalling is, but this all
comes down to a task known as serialization and that's the real solution
to all such problems where you want store arbitrary data in blobs or
whatever. For c++ I use boost::serialization and I can put quite crazy
(multiple inherited & polymorphic) big objects into sqlite without even
knowing how to to put PODs into sqlite blobs
