Message-ID: <c=GB%a=_%p=Indigo_Active_Vi%l=CRIANLARICH-970319165430Z-327@crianlarich.Indigo>
From: Robert Humphris <r DOT humphris AT indigo-avs DOT com>
To: "'Alaric B. Williams'" <alaric AT abwillms DOT demon DOT co DOT uk>,
        "'David McKee'"
	 <david DOT mckee AT rtp DOT gtegsc DOT com>
Cc: "'djgpp AT delorie DOT com'" <djgpp AT delorie DOT com>
Subject: RE: Persistence in Djgpp
Date: Wed, 19 Mar 1997 16:54:30 -0000
Encoding: 34 TEXT

On the subject of Persistence of objects...
>The routine you have proposed is how it is basically done by most 
>developers who use compilers without explicit persistence.  The
>binary can then be saved into files or a database (say, as a blob).
>Still, what I would like to see is a "top" class that could be 
>used as the parent of all classes that need to be persistent.  And
>they simply would be.  All serialization, storage, and recovery would
>be done "transparently" with options allowed to do specific things
>such as "destroy", mem space copy, etc.  A total package if you will
>based on ideas and proposals bu the C++ standards committee perhaps.

I am currently working on a Framework that provides a nice set of
classes that will enable
the user to inherit such things as list, string, tree etc. Persistence
is supported by the very base
parent object in so much as it will enable classes to be packed into a
flat buffer which can be saved to
disk, or squirted down a serial port, tcp/ip socket connection what
ever...

I would like to release a very low functionality version so that people
can add,change whatever they
think is needed.  At the very basic level the design is a cross between
some of the MFC classes, and
the Booch framework design.

>At any rate, I will probably write something to this effect for my 
>own needs, and if it's any good I'll offer it up.
Well if we put both of our efforts towards it we may save some time and
effort and not end up writing
the same stuff as each other.

>Rob Humphris
>