naive serialization

[nw]

Hi,

I have some simple objects I wish to serialize and I'm wondering
what's wrong with the following naive approach. The objects will never
contain pointers or references to other objects, they are simple
containers of primitive types.

The serialization method I'm using simply takes the base pointer of
the object, then dump the memory from base pointer to base pointer +
sizeof(object). To deserialize the object the dumped representation is
written over the memory space of a newly instantiated object.

So, I can understand this isn't a great idea. But is it outside the
standard? Is the memory layout of a class guaranteed to stay the same
(during execution)?

Example serialization method (writes serialized representation to
storage_area), in my implementation object_type is a template
parameter:

void set(size_t index,const object_type &o) {
size_t write_end_position = (index+2)*(object_size);

for(size_t n=0;n<object_size;n++) {
storage_area[(index*object_size)+n] = ((const char *)(&o))[n];
}
}

Example deserialization method (reads from storage_area):

object_type get(size_t index) {
object_type o;
for(size_t n=0;n<object_size;n++) {
((char *)(&o))[n] = storage_area[(index*object_size)+n];
}

return o;
}

 

[Goran]

Hi,

I have some simple objects I wish to serialize and I'm wondering
what's wrong with the following naive approach. The objects will never
contain pointers or references to other objects, they are simple
containers of primitive types.

The serialization method I'm using simply takes the base pointer of
the object, then dump the memory from base pointer to base pointer +
sizeof(object). To deserialize the object the dumped representation is
written over the memory space of a newly instantiated object.

So, I can understand this isn't a great idea. But is it outside the
standard? Is the memory layout of a class guaranteed to stay the same
(during execution)?

Yes. But during multiple executions, with some re-compilations in the
middle, no. And THAT is going to be your problem in practice.
Serialization is tricky with schema changes.

Example serialization method (writes serialized representation to
storage_area), in my implementation object_type is a template
parameter:

void set(size_t index,const object_type &o) {
  size_t write_end_position = (index+2)*(object_size);

  for(size_t n=0;n<object_size;n++) {
    storage_area[(index*object_size)+n] = ((const char *)(&o))[n];
  }

}

memcpy? No? ;-)

Example deserialization method (reads from storage_area):

object_type get(size_t index) {
  object_type o;
  for(size_t n=0;n<object_size;n++) {
    ((char *)(&o))[n] = storage_area[(index*object_size)+n];
  }

Goran.

 

[Juha Nieminen]

I have some simple objects I wish to serialize and I'm wondering
what's wrong with the following naive approach. The objects will never
contain pointers or references to other objects, they are simple
containers of primitive types.

It's somewhat of a design problem because you have to somehow make sure
that at no time in the future will any pointer or complex type be added
to such an container (such as eg. a std::string).

Also the file created by such serialization is not portable between
different systems, but that might not be a problem in your case.

 

[Marcel Müller]

Hi,

I have some simple objects I wish to serialize and I'm wondering

what do you call simple? Are they PODs?
If so, then you have defined behavior, as long as you do not change the
platform or the structure.
If they are not PODs you have undefined behavior.

what's wrong with the following naive approach. The objects will never
contain pointers or references to other objects, they are simple
containers of primitive types.

If they do not have virtual functions, then you have POD object and
anything is fine (with the above restrictions).


Marcel

 

[Goran]

ok, that's fine. My application is basically using the storage as
virtual memory during execution.
I was asking because gcc 4.3 seems to have problems with my method at
times. 4.5 seems fine.

In the case of the sort of the code you've shown, this is very
suspicious. It is much, MUCH more likely that you have a bug and that
you only saw it when running code built with one version of the
compiler. Another, less likely problem, is that there really is a
difference between two compilers that somehaw makes your bug visible.

Goran.