Re: a specific constructor to help supporting persistence?
* t_grellier@yahoo.fr:
Persistence can be supported by serialization or dump of memory state.
Problem arises when one want to retrieve complex data structure with
minimal coding, or ensure some ACID properties to the persistence,
because of limited C++ reflexivity.
Boost has a serialization library that relies on a default
constructor. And for example POST++ also reserve the default
constructor to perform data restore and rely upon persistent virtual
memory.
I guess they use something like:
unserialize(data, new C);
for each member, parent of C, unserialize(member)
and
new(pdata) C;
for each pointer in C, restore pointed object
The motivation to reuse default constructor it is implicitely call in
herarchical construction with a default behavior of doing nothing. But
this has the drawback to reserve the default constructor, which limits
reuse of existing code.
With boost like serialization one must be careful not to allocate
memory in default constructor or then to clean it when unserializing.
And with POST++ solution, you just can't use the default constructor.
So the idea would be to introduce in the language a persistent
constructor that enables unserialization without disturbing the
default constructor. Like the default constructor, its default
behavior is call persistent constructor for each member and parent
classes, and for literals do nothing.
its syntax could be
class C {
C(static); // not to introduce new keywords
};
Any comments?
Two.
First, you don't need language support for that, but automatic
code-generation can be practically useful.
Second, a main reason why common serialization frameworks are based on
two-phase initialization is that this simplifies the serialization code
to the degree that /the same code/ can handle serialization both ways.
I agree that two-phase initialization is Evil(TM).
The challenge, if, by a million-to-one chance the developers in one's
company actually take advantage of the single-code serialization
possibility instead of redundantly coding the in and out serialization
separately and with different bugs and maintenance horrors, and if one
doesn't consider the advantages of single phase and disadvantages of
two-phase initialization to be enough to outweight the disadvantage of
the resulting separate serialize-out and serialize-in code (that's a lot
of ifs), is to come up with some relatively simple way to allow
single-phase initialization and yet have single-code serialization.
That would be something.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]