Serialization of a template data type

Also, you might want to take a look at Boost serialisation. It might help you out.
http://www.boost.org/doc/libs/1_40_0/libs/serialization/doc/index.html

Thanks very much for the info evilrix.  I've read through some of the documentation on Boost.  Do you happen to have a pointer to an example that handles templated data up your sleve by any chance?

Thanks again.

>>>> UseWARNING: Remember this can only safely be used for PODs
A method that works both for POD and class types (only if POD types have same size for all particpients) is to have global serialize and deserialize functions for each type supported, e. g.

archive & serialize(archive & aout, const int& i)
{
     int hi = htonl(i);
     return aout.write(&ui, sizeof(int));
}

...

archive & serialize(archive & aout, const A& a)
{
     aout.serialize(aout, a.i_member);
     aout.serialize(aout, a.str_member);
     aout.serialize(aout, a.dbl_member);
     aout.serialize(aout, a.otherclass_member);
     return aout;
}

You even could serialize pointer or array members that way though of course not as pointers but by serializing the object the pointer is pointing to.

I'm pretty certain I've already said as much...

"If the types are never going to be PODs and always user defined types either overload namespace level operator <<(ostream &amp;, <yourtype> &amp;) or implement serialise and deserialise methods on your class.

{http:#25358143}

Thanks!  I believe I understand all the issues involved now.

>>>> either overload namespace level operator <<(ostream &amp;, <yourtype> &amp;)
Overloading the ostream operator is less recommended as general output rarely is suitable for serializing and you reasonably can only have one global operator<< implementation for a type. But of course you could overload the operator<< and operator>> for your own archive class instead of using functions serialize/deserialize

class archive
{
    unsigned char buf*;
    unsigned int sizalloc;
    unsigned int sizfilled;
public:
    archive() : buf(NULL), sizalloc(0), sizfilled(0) {}
    friend operator<<(archive & ar, const int& i)
    {
         ar.write(&i, sizeof(int));
         return ar;
    }
    // add more operator<< overloads for POD types
    void write(void * p, int siz)
    {
         if (sizalloc < sizfilled + siz)
        {
              unsigned char* newbuf = new unsigned char[sizalloc + CHUNK_SIZ];
              if (buf != NULL)  
                 memcpy(newbuf, buf, sizalloc);
              memset(&newbuf[sizalloc], 0,  CHUNK_SIZ);
              delete []buf;
              newbuf = buf;
              sizalloc += CHUNK_SIZ;
         }
         memcpy[&buf[sizfilled], p, siz];
         sizfilled += siz;
    }
};

archive & operator<<(archive & aout, const A& a)
{
     aout << a.i_member << a.str_member <<  a.dbl_member << a.otherclass_member;
     return aout;
}


>>>> or implement serialise and deserialise methods on your class.
class members are a means to have serializing for class types only. My suggestion was to using global serialize/deserialize functions in order to have a universal solution for POD types and non-POD types.

I used that method in a few projects with good success.

>> Overloading the ostream operator is less recommended as general output
Authoritative reference?

>> reasonably can only have one global operator<< implementation for a type.
Use an adapter or a stream manipulator if this is really a valid use-case.

>> for serializing and you reasonably can only have one global operator<<
It is important you place the operators in the same namespace as the class they are designed to serialise and deserialise to avoid ambiguities with other types that may share the same name. You can rely on ADL (Argument Dependent Lookup) to ensure the correct operator is called without having to fully quality the operator with the namespace.
http://en.wikipedia.org/wiki/Argument_dependent_name_lookup

>> My suggestion was to using global serialize/deserialize functions in order to have a universal solution for POD types and non-POD types.
Intrinsics already have overloaded stream operators, for you own user defined struct/class you just need to overload namespace level stream operators. This keeps things nice and simple; you can then serialise to any type of stream that supports the standard istream and ostream interfaces without writing any addition code or changing any syntax/semantics. You can also template the namespace level stream operators to provide more generic behavior.

>> // add more operator<< overloads for POD types
Why not just use a template as I did above? You then only need to write one function, specializing if necessary for other types.

>>>> I'm pretty certain I've already said as much...
I was missing your pardon about wrongly accusing me to have repeated what you already said ...  


>>>> Overloading the ostream operator is less recommended as general output
>> Authoritative reference?
It is a practical advise by me. I have done serialising in various projects and mixing up output streaming with serialisation has not one single benefit. You need the operator<< for (normal) outputs and it is not senseful to using different implementations or manipulators as it makes things unnecessarily complex (thus error-prone). Instead of using the ostream class it is much more straight-forward to using an archive class as you have to care for the archive (e. g. by handling endianess issues) in a special way anyhow. If you did that once, you would know that streaming is one of the minor issues to care for.

>>>> you just need to overload namespace level stream operators. This keeps things nice and simple
Truly simple. Playing around with namespaces is a sure method to precipitate a project into desaster. How will you find out whether the right implementation was used in code of some millions of lines?