By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,171 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,171 IT Pros & Developers. It's quick & easy.

C++ and persistent objects

P: n/a
Typically C++ persistence implementations, (from the little I've seen),
boils down to something like this:

myclass {
int ivar;
float fvar;
...

saveyourself( file )
{
file.write(ivar);
file.write(fvar);
...
}

};

With this approach we always have to write the code to unwind the variables
to or from the storage media. This can be a big job for objects that involve
complex class hierarchies, and it could impact performance as well.

Another approach is to write/read binary chunks and then use inplace
activation techniques. This is better but what happens when the structure
changes ..., then you need to write conversion functions and you end up
writing code similar to the above where you need to unwind the variables
again.

I'm thinking there must be a better way. After all isn't this exactly what
COM and Corba or XML does to marshal an interface or data structure. With
these frameworks you generally don't have to do the unwinding code yourself
there is typically a tool that does it for you. Is there a way to leverage
these tools to solve the C++ persistence problem, or perhaps there is some
other code available? Am I missing something here?
Any suggestions or links?

Thanks,
Perry.


Jul 22 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Perry St-Germain wrote:
Typically C++ persistence implementations, (from the little I've seen),
boils down to something like this:
Ah - a favorite topic of mine ...

These are a couple of URL's to google past comp.lang.c++ posts on this
topic.

http://tinyurl.com/vgbc
http://tinyurl.com/vgbs


myclass {
int ivar;
float fvar;
...

saveyourself( file )
{
file.write(ivar);
file.write(fvar);
...
}

};

With this approach we always have to write the code to unwind the variables
to or from the storage media. This can be a big job for objects that involve
complex class hierarchies, and it could impact performance as well.

Another approach is to write/read binary chunks and then use inplace
activation techniques. This is better but what happens when the structure
changes ..., then you need to write conversion functions and you end up
writing code similar to the above where you need to unwind the variables
again.

I'm thinking there must be a better way. After all isn't this exactly what
COM and Corba or XML does to marshal an interface or data structure. With
these frameworks you generally don't have to do the unwinding code yourself
there is typically a tool that does it for you. Is there a way to leverage
these tools to solve the C++ persistence problem, or perhaps there is some
other code available? Am I missing something here?
Any suggestions or links?


I have found that the fastest form of IO on almost any platform is a
mapped file. C++ has no built-in support for mapped files so you're in
OS dependant land but this is a very thin layer.

You could theoretically make a "portable" format for mapped files that
works on a large subset of computing platforms today.
Jul 22 '05 #2

P: n/a

"Perry St-Germain" <px*************@videotron.ca> wrote in message
news:yj*********************@wagner.videotron.net. ..
Typically C++ persistence implementations, (from the little I've seen),
boils down to something like this:

myclass {
int ivar;
float fvar;
...

saveyourself( file )
{
file.write(ivar);
file.write(fvar);
...
}

};
This is serialization, which can be used to implement persistence. Join the
boost.org development mailing list where Robert Ramey is refining an
implementation which he is planning on submitting to boost. He's separated
the medium ( text/binary/xml/... archives ) from the serialization
machinery. His library supports both non-intrusive as well as intrusive
serialization capabilities.
With this approach we always have to write the code to unwind the variables to or from the storage media. This can be a big job for objects that involve complex class hierarchies, and it could impact performance as well.
I assume by "unwinding" you mean "load"? You may handle load/store with a
single serialize function ala:

template<class Archive>
void serialize( Archive &ar, unsigned int version )
{
ar & ivar;
ar & fvar;
}
Another approach is to write/read binary chunks and then use inplace
activation techniques. This is better but what happens when the structure
changes ..., then you need to write conversion functions and you end up
writing code similar to the above where you need to unwind the variables
again.

I'm thinking there must be a better way. After all isn't this exactly what
COM and Corba or XML does to marshal an interface or data structure. With
these frameworks you generally don't have to do the unwinding code yourself there is typically a tool that does it for you. Is there a way to leverage
these tools to solve the C++ persistence problem, or perhaps there is some
other code available? Am I missing something here?

The only systems of this ilk that I know of are:

http://www.cs.utexas.edu/users/oops/papers.html#texas

Which is a research project at university of texas. I haven't seen any work
done on this in quite some time.

http://www.objectstore.net/products/index.ssp

A commercially available system. Quite powerful/large/complex, but does what
your asking for.

What these systems generally require is some sort of external definition
language akin to COM's IDL. IMO this is a major drawback, requiring
knowledge of another language and maintenance of another set of code. Bjarne
Stroustrup has a paper on XTI - Extended Type Information Library - that
possibly could negate the need for this redundancy.

Persistence is much more complex than one first imagines. Robert Ramey's
serialization library, IMO is the most comprehensive, easiest to use and
least expensive(free) alternative that I've seen.

-----------------
Jeff Flinn
Applied Dynamics, International

Jul 22 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.