Progress Update

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

This all took me alot longer to get around to do than I would've liked.
Here's an update on what I've been up to:

--

Ok, first off, I've coded and fully debugged the hash table part of the
directory class.

The hash table is implemented as a seperate, templated HashTable class that
is fully configurable for just about any porpuse. The hash table can
serialize itself from and to storage, it can add and remove (via another
class) entries, it can extract entries based on a key and there is an
external forward-only iterator. In short, its a complete implementation of
the functionality we need.

Editing a hash table is done via another class of the name DynHashTable. The
basic HashTable class cannot be edited, only serialized and reset.
DynHashTable cannot be serialized, and it cannot extract entries based on a
key. It can, however, add and remove entries.

The class HashTable has a method that will allocate an instance of type
DynHashTable and transfer ownership of the array that holds the contained
entries to this instance. This instance is then returned. Another method of
HashTable copies the content of a DynHashTable instance to the HashTable.

Thus, to edit a HashTable, one needs to call ConvertToDynTable(), edit the
returned DynHashTable, and then call CreateFromDynTable(), passing the
DynHashTable as its parameter. The DynHashTable can then be deleted.

DynHashTable stores its entries by means of both an entry (the initial data
from the HashTable that created it) and a linked list (data added later).

This is the most effecient implementation I could think of for editing the
hash table.

The only uneffecient part of the hash table is the method that takes care of
resorting the entry array. This uses a simple selection sort algorithm. I
plan on changing that shortly, though.

The complete list of new hash table related classes are:

>**HashTable.h
HashTable
DynHashTable
HashTableIterator
HashTableMisc

>**DelPtr.h
DelPtr

DelPtr is the light auto_ptr version we talked about. These classes are all
fully documented. These classes all follow the new naming and namespace
conventions.

--

I updated the documentation and code of the following classes to make them
follow the new naming and namespace conventions:

>**MemAlloc.h
MemAlloc
ObjAlloc

>**StatMemAlloc.h
StatMemAlloc
StatObjAlloc

>**DynMemAlloc.h
DynMemAlloc
DynObjAlloc

I haven't actually run diagnostics on this to ensure that changing the names
doesn't break anything, but it compiles, and I can't think of any situation
in which the compiler wouldn't pick up on any errors that can be thougth to
be the result of this name-changing.

--

I have only implemented the actual Directory class very lightly. The reason
for this is partly that I'm not entirely sure exactly what the interface
should be capable of (the same as the old?).

Also, on pak-file structuring (talking only format 0 here), I'm having a
hard time finding out exactly the correct format. This is the fastest and
easiest way I can think of right now:

*pak header*
-pak dir data and DIR content-
-pak file data-
-pak file content-

Ie, to write a pak file, this is what happens:

*write pak header
*write top-most directory info (amount of files and dirs etc.)
**the data of the first directory contained in top-most directory
***the data of the first directory contained in that directory
***the data of the second directory contained in that directory
*** etc.
**the data of the second directory contained in top-most directory
***the data of the first directory contained in that directory
*** etc.
** etc.

Now, we've got all the dir data, now for the file data.

*write top-most directory file info (amount of files and dirs etc.)
**the file data of the first directory contained in top-most directory
***the file data of the first directory contained in that directory
***the file data of the second directory contained in that directory
*** etc.
**the file data of the second directory contained in top-most directory
***the file data of the first directory contained in that directory
*** etc.
** etc.

Basically, the same thing, just for the file data. The actual file content
then follows. Notice that we don't have to store the position of anything
but the actual position at which the content of each file starts. The rest
is made clear by the position each dir and file-info block holds in the
file, and these's lengths.

This is easiest done by recursion:

WritePakF0(FILE* pStream)
{
	-write info for this dir-
	-write all dirs, calling WritePakF0(pStream) recursively-
	-write info for files-
}

Same thing for reading, just different names for the called methods.

--

It would be nice if the rest of the PPlay symbols could be changed to the
new naming and namespace conventions. What's the estimated time frame for
this?

--

How do I read .sgml files?

--

Do you want me to implement a more effecient version of the URL processing
functions? Or will you do that?