# Serialization design issues

## Recommended Posts

Hi! I'm trying to design basic serialization for my current project. But I cannot resolve one design issue. I have a class with array of some basic types(say floats). When I serialize it, serializer first writes array's size and than array itself. But now I want to unserialize it. How to do it if I don't know what the size of array is (it's written in file) so I cannot allocate space for data and if my unserializer does, who should destroy the array? Hope you understand. Thx in advance

##### Share on other sites
Couldn't you write a class to wrap up the data and use a constructor as deserializer (and add another method for serialization)?

##### Share on other sites
1) I might suggest using STL primitives such as std::vector so that they'll be destroyed when they go out of scope.

2) Example:

struct data_to_serialize{    std::vector< float > array_of_floats;    void write( std::ostream & os );    void read( std::istream & is ); //note: replaces existing data};void data_to_serialize::write( std::ostream & os ){    std::size_t n = array_of_floats.size();    os.write( &n , sizeof(n) );    for ( std::size_t i = 0 ; i < n ; ++i )    {        float f = array_of_floats[i];        os.write( &f , sizeof(f) );    }}void data_to_serialize::read( std::istream & is ){    array_of_floats.clear();    std::size_t n;    os.read( &n , sizeof(n) );    array_of_floats.resize(n);    for ( std::size_t i = 0 ; i < n ; ++i )    {        float f;        os.read( &f , sizeof(f) );        array_of_floats[i] = f;    }}

##### Share on other sites
Checkout:

http://www.boost.org/libs/serialization/doc/index.html

HTH

/Marcus

##### Share on other sites
Quote:
 Original post by marcuszCheckout:http://www.boost.org/libs/serialization/doc/index.htmlHTH/Marcus

Fixed.

##### Share on other sites
Through my own coding, and much of the posting here, I've come to conclude that c/c++ arrays are the spawn of the devil. They confuse beginners, introduce design issues and generally suck.

The modern container classes [for high level] or blocks o' memory [for low level] are much better off I'm finding.

Alas, to use the first requires at least a basic knowledge of templates, and to use the second requires a heafty knowledge of pointers. Both of which are traditionally taught -after- the student needs to know about arrays.

Anyways, I would have the unserializer do it. From a programmers' perspective, calling the unserializer is like calling new. There is an object made from nothing, and now the programmer needs to deal with it's destruction. If the array is a member of the class like you say, I'd have the classes constructor and destructor handle the allocation/deallocation of the array's memory. That way the class has a standard interface, and you don't need to remember how it was made to know if you need to clean up the array seperately.

##### Share on other sites
Actually, I've been tinkering with my own serializer now for a bit. I haven't got that far in programming it (most of it has been done out on paper) but I'd like to be able to inherit the properties of the "Serialization" interface and then use some sort of Macro combination to decide what members are going to be written to disc (and thus, reloaded as well). Just an idea of mine; not sure if it's going to have much practical use outside of it being an idea.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628349
• Total Posts
2982210

• 10
• 9
• 24
• 11
• 9