Container persistence (save/load)

[jacob navia]

In my book of about the C++ stl (Plauger/Stepanov/Lee/Musser) there is
nothing about saving a container to disk or loading it from a
file/stream.

Probably because you overload the << and >> operators for that,
I do not know.

In any case I think the container library in C should have at least
the following additional methods for

(1) Saving a whole container into a stream in text mode
(2) The same in binary mode
(3) Loading a whole container from a stream in text mode
(4) The same in binary mode.


Now, the prototype for Save/Load could be:

container->Vtable->Save(container, Stream, ApplyFunction, arg);
container->Vtable->Load(container, Stream, ApplyFunction, arg);


where:

container: The container we are saving or loading. Should
be empty in the case of load. The library will
call anyway Clear() before loading anything.

Stream: The file where we are reading/writing from/to.

ApplyFunction: Function called for each element in the container.
It defaults to a function that writes the bytes in
the container either in ascii or in binary form.
A value of NULL means default.

arg: Argument to pass to each call of the callback. Can
be NULL.

The prototype for the ApplyFunction is:

int ApplyFn(void *element, void * arg, FILE *stream);

element: Points to the element to be saved/read
arg: Argument passed to the Save or Load function.
stream: File where the data is read or written.

What do you think?

Did I forget something?

Thanks

 

[Ike Naar]

In my book of about the C++ stl (Plauger/Stepanov/Lee/Musser) there is
nothing about saving a container to disk or loading it from a
file/stream.

Does your book describe istream_iterator<> and ostream_iterator<>?

 

[Ian Collins]

In my book of about the C++ stl (Plauger/Stepanov/Lee/Musser) there is
nothing about saving a container to disk or loading it from a
file/stream.

Probably because you overload the << and >> operators for that,
I do not know.

The biggest issue there and here is you need and standard method to
marshal (serialise) the objects stored in the container. Neither C or
C++ have built in support for object serialisation.

In any case I think the container library in C should have at least
the following additional methods for

(1) Saving a whole container into a stream in text mode
(2) The same in binary mode
(3) Loading a whole container from a stream in text mode
(4) The same in binary mode.

Now, the prototype for Save/Load could be:

container->Vtable->Save(container, Stream, ApplyFunction, arg);
container->Vtable->Load(container, Stream, ApplyFunction, arg);

where:

container: The container we are saving or loading. Should
be empty in the case of load. The library will
call anyway Clear() before loading anything.

Stream: The file where we are reading/writing from/to.

ApplyFunction: Function called for each element in the container.
It defaults to a function that writes the bytes in
the container either in ascii or in binary form.
A value of NULL means default.

arg: Argument to pass to each call of the callback. Can
be NULL.

The prototype for the ApplyFunction is:

int ApplyFn(void *element, void * arg, FILE *stream);

element: Points to the element to be saved/read
arg: Argument passed to the Save or Load function.
stream: File where the data is read or written.

Does this need to be part of the container? The C++ way would be to
provide a function to std::for_each (which iterates through the container).

 

[jacob navia]

Ike Naar a écrit :

Does your book describe istream_iterator<> and ostream_iterator<>?

Yes, but they do not seem to save/load a whole container from a stream.
They only save elements of the stream into it. Probably it is not that
difficult to do once you have the saving of the elements but it didn't
look easy to me.

In any case the book tells about overloading << and >> to read/save
elements, and that would correspond to the ApplyFunction in my
proposition in the other message.

 

[jacob navia]

Ian Collins a écrit :

Does this need to be part of the container? The C++ way would be to
provide a function to std::for_each (which iterates through the container).

The header must be saved too. The state of the container, its flags,
must be saved, together with any specific data like element size
etc. If you just iterate the elements the header information is lost.

Header info allows you to know how many elements you will read
BEFORE you read them. This allows for the storing of several
containers in the same stream.

A function to save/load is supposed to be given to the save/load
functions. The only difference To C++ tsd::for_each is that here there
is a prepared default function that allows you to save some container
into a file and read it back later without much effort. I do not see how
would you add a default into C++ for_each.

This could be useful when saving context from a session into a next
session. For instance a string collection would be handy to save a list
of open files to/from disk.

Obviously since the disk is a linear media, I will write only the
functions for ArrayList, and then I will write functions in all other
containers to transform to/from ArrayList instead of writing a specific
function for each one. The exceptioncould be the concrete containers
like bit-string, for instance.