Alain Coetmeur <acoetmeur@icdc.caissedesdepots.fr> wrote:
>
>why not add in C++ support for different serialization
>models... for example XDR (sunrpc),NDR(DCE), RMI, Corba's, IIOP,...
>like anything in C++ it have to be fully open and
>adaptable...
>
>how give enough self awareness to C++ classes
>so they can serialize themselves
>without locking to a single serialization model
>(ie XDR good, but not NDR...)
>
>I have an idea based on my XDR experience in C++...
>(I've made a C++ RPC )...
>my experience is that you can build a serialization scheme
>by overloadin a
>bool serialize<ser_model>(ser_stream::ostream&,const object&)
>bool deserialize<ser_model>(ser_stream::istream&,object&)
>so that it call recursively the same function for the members...
>for any objects...
>add templates to serialize containers, auto_ptr,
>basic c types, strings,.... and you have quite all...

I tried to do this once, but I found that I couldn't determine how to
serialize an object by looking at the types of its fields, especially
given a pointer to an object, T* x:

 1.  It could be that it points to an object of type T.
     In this case, it could be either:

     HAS-A: The current object _owns_ x, in which case I should
   always serialize x;
     REFERS-TO:  The current object knows about x / refers to x,
   so x might be shared.  In this case, some kind
   of sharing information needs to be stored for
   x.  If it's already been written, it won't be
   serialized again.

     In either case, x's actual type could be a subtype
     of T.

 2.  It could be that it points to an array of T objects.
     In this case, I need to serialize an array, and I
     know they must all be of type T (not a subtype).

These two problems could be avoided by requiring that people use
auto_ptr<T> for owned objects and vector<T> for arrays, but then it
wouldn't be completely general.

Also, it couldn't be completely general for invariants.  For example,
I may have an invariant that says that each instance of an object gets
a unique ID field.  If I serialize an object and then unserialize it
twice, then the hypothetical standard C++ unserializer would be
incorrect.  The problem with invariants is also likely to come up with
something like a 'lock' object that locks a resource, since
serializing an open lock and then unserializing it twice would mean
trouble.  You'd have to write a custom serializer for these classes;
perhaps it would just throw an exception.

A standard serializer wouldn't work for outside resources.  For
example, in many GUI systems, you can get a handle (typically an int
or void*) to a window, a menu, a dialog box, a font, etc.  If the
serializer template just looks at the type and saves the int, that int
won't work when the object is unserialized.  The same would be true
for file handles or network connections.  You'd have to write a custom
serializer for these classes.



Anyway .. I'd really like to have a complete general serialization
library, but I don't really know how one can be written to handle all
the cases involving pointers.  :(  You'd also have to somehow make
sure that all the fields of an object were initialized .. a property
that isn't guaranteed in C++.

 - Amit
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

--MimeMultipartBoundary
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

why not add in C++ support for different serialization
models... for example XDR (sunrpc),NDR(DCE), RMI, Corba's, IIOP,...
like anything in C++ it have to be fully open and
adaptable...

how give enough self awareness to C++ classes
so they can serialize themselves
without locking to a single serialization model
(ie XDR good, but not NDR...)

I have an idea based on my XDR experience in C++...
(I've made a C++ RPC )...
my experience is that you can build a serialization scheme
by overloadin a
bool serialize<ser_model>(ser_stream::ostream&,const object&)
bool deserialize<ser_model>(ser_stream::istream&,object&)
so that it call recursively the same function for the members...
for any objects...
add templates to serialize containers, auto_ptr,
basic c types, strings,.... and you have quite all...

you could just have to add directives
like "transient" or "persistent" to members
so that it can direct which members to serialize or not...
perhaps could it be possible to add
"persistent" function members pair that
represent a "get" and "set" accessor
on a virtual member whose value should be serialised
and that sould be set by unserialization...
set would be detected because of the
parameter, et get be cause of the non void return...
managing case union (choice), especially the case
of class hierarchy (class determine what is what)
can be also a problem, but perhaps
just delegated to the user...
in this case there should be a
ser_model::class_code_type
base_class::class_code<ser_model,base_class>()
that an auto_ptr<base_class> could use by default
and should serialize before the object itself...
on unserialization there should be a way to detect to which
class the class_code point to...
perhaps a
static base_class*
new_with_class_code<ser_model>(ser_model::class_code_type)
more generalyy ther should be a way to obtaine automatically
a "class code" and "new with code" function that from a
conventional (defined or automaticaly generated) code
can create an instance of a derived class...
I've not finished all my need, since it would take
weeks to finish it, but with programmers as samrt
as those of the STL
the compiler would only need to generate
a few template function folowing class structure and
hierarchy... I've seen just now:
a serialize template that call serialize for each
"persistent" member... including a way to add computed members...
or more generally something to call a template function
given the members list (modified with persistent/transient modifier)...
a "new with class code" perhaps a
"static call with class code", given a class code function...
it need also a "which class code I am" virtual member
that calls the static "which calss I am", used by the
"* with class code"...
another implementation of the "* with class call" could be
a dynamic registration of classes at runtime...
since a base class might not be aware of derived class,
it seems more reasonable than asking the compiler to
list all derived classes...



--
Alain Coetmeur. Informatique-CDC , mailto:acoetmeur@icdc.caissedesdepots.fr
<<Mes propos n'engagent que moi. #8*). my words are only mine. >>


--MimeMultipartBoundary--
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]