🚀 go-pugleaf

In <6v3uei$593$1@shell17.ba.best.com> jbuck@best.com (Joe Buck) writes:

>Nick Andrew <nick@zeta.org.au> wrote:
>>It occurred to me on discussing this issue that perhaps the save format
>>(what is written to disk) may be closely related to the data structures
>>used in the program.

>That's correct.  Microsoft is fond of "serialize", a scheme for dumping
>an image of a C++ object hierarchy to disk.  The system is rather poorly
>designed and inflexible (there is a versioning system but it requires
>base classes to know version numbers of derived classes and other evils
>like that), but it has the small benefit of giving programmers a simple
>way to do a persistent store.

I have a program that generates portable, albeit not dead fast, code
for unpacking this format without going for the Software AG/M$
solution of getting the compiler to pack everything, despite any
inefficency and other things indicating this is a bad idea. (ARM users
will suffer *very badly* when a 32 bit number starts at an address
that is not a multiple of 4---it takes two reguisters and some calculation
to load the value).

Release date will depend on volume of yelling at me. (More
yelling==earlier release date and rougher edges). Note that we can do
serialise in linux too if we really want to write non-portable data
formats.

I have plans to actually do this for temporary storage for a program
that generates a table given a few numbers. Table size depends
primarily on n and p. n=100 and p=2 looks like many 10s of Mb (I
guessistmated 80Mb). n=100 and p=3 looks more like 80000Mb.

Duncan (-: