Walter wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374884983818403@news.digitalmars.com...
>

>
>> On Mon, 19 Aug 2002 16:35:23 -0700 "Walter"
>> <walter@digitalmars.com>
>>
> wrote:
>
>>> At least by comparing the contents of ClassInfo, you'll know
>>> when you
>>>
> broke
>
>>> it <g>.
>>>
>> ClassInfo contains a string (class name), initializer, and a
>> couple of pointers. It is probably not the best idea to save
>> pointers to a disk file...
>>
>
> ClassInfo will eventually be extended to know about the members and
> their offsets. An overloaded eq() for it would be able to follow the
pointers and
> properly compare the contents.

Sigh.  I've been waiting for someone to ask, but you three keep on
circling around it, so this is what I do for my pickling.

The class name is saved, which contains the full name up to the module.
  Then the parent class is saved.  Then the field names and types are
saved.  Everything is done once only.  A small class takes about thirty
bytes.

For loading, we take in that name and find it or not, giving a solid
error message if there's a problem.  Finding the class to load into is
just a name search, as we match each field individually, allowing new
fields to be added or fields to be moved around.  If a field changes
type or is deleted, it throws up, again with a good error message.

This transfer is also done for types.  From then on, the type is
referenced with a single byte, or more if necessary (variable-sized
integers are used everywhere).  Pointers, class references, and arrays
also use these single-transfer handles, so that aliasing is retained.

Array range aliasing is not retained - if an array is a range of another array, and they're both saved, the arrays will be made unaliased in loading.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374890214802662@news.digitalmars.com...
>But then it seems like a step to persistance built into the language
>(which would IMO be great!).

I wanted to do that originally, but gave up on it as too complicated for now.

>By the way, anybody knows of some good reliable way to store object references into file, so they can be retrieved later?

A technique I've used is to store memory mapped files at fixed addresses.