Problems

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

I'm having some problems getting stuff to work together, and generally
getting stuff to work at all. Here are the most important:

**** The std namespace
I don't know about your implementation of the standard C++ library, but in
mine, the header cstdio does not put FILE into the namespace ::std, but
rather the global namespace. To me, this seems a bit weird, but that's
what's happening.

Very, very weird is the fact that the template functions min and max are NOT
defined in the header algortihms.h as they should be. The best I get in
cstdlib is this:

#define __max(a,b)  (((a) > (b)) ? (a) : (b))
#define __min(a,b)  (((a) < (b)) ? (a) : (b))

and this:

#ifndef __cplusplus
#define max(a,b)    (((a) > (b)) ? (a) : (b))
#define min(a,b)    (((a) < (b)) ? (a) : (b))
#endif

This seems to me to be a major flaw in the implementation. I could of course
have got it all wrong.



**** The current serialization scheme
It'll all have to change to incorporate the new serialization scheme. The
current stuff simply doesn't fit into the new Directory implementation.

The current serialization scheme seems somewhat more complicated than
needed. Just what is the reason for having two passes rather than just one?
I think its alot more effecient (and simple!) to do a little processing
before hand so that all information is present before the first pass,
meaning that only one pass is nessecary. Is there something I'm overlooking
that makes this impossible?

I really don't like the way recursion is performed via the GetNext() method
of DirEntry. If one has a thousand files in a directory, one will get a call
stak a thousand methods deep...

Why all the ppf_PakMWriteLEIntXX() stuff? I mean, memcpy works just as well,
and its much clearer what's going on... Its faster too. Atleast my
implemenation is, as its inline assembly that goes to the next 4-byte border
and then copies 4 bytes at a time.

Why store a pointed to the parent of each item in the actual pak file?
Atleast in the serialization scheme of Directory, the parent will always be
the one calling the serialization method of the child, so who the parent is
will already be known, and the calling code can set this.

It seems that the varying-length nature of the name string is screwing
things up when writing data. Why not just write it to the file before
creating the in-memory buffer of the rest of the info? That way, it can be
ignored alltogether.

The basic nature of the incompatibility of the current / new serialization
scheme is that the new serialization scheme is build up around the paradigm
that directories should serialize their children and themselves and have
responsibility for nothing else. Files should have responsibility for
nothing but serializing themselves. This is all kept to a need-to-know
basis, in that the only thing each step in the process recieves is an open
stream. Well, actually, each process can also request the information of
where in the file the header ends, so that the position of the content of
serialized files can be determined, even before they are written (this
position is then updated whenever a file reserves future space for its
content).

In the current serialization scheme, each and every step in the process is
required to initiate the next step in the process, even if this other step
is completely unrelated to its own functioning (like a file requesting
another file to serialize). Atleast, that's how I've understod it.

The new scheme offers a framwork that makes everything independent, and this
is incompatible with the current way of doing it. This means I'm going to
have to change alof of stuff to get it to work. I thougth I had better run
this by you first.


**** Those SetParent() methods all over
All SetParent() methods call Remove() on their former parent. Wouldn't the
former parent always be NULL ? Are anything ever really moved (ie, changing
parent) ?



**** Constants
How about moving constants from Const to pp::internal:: ?



**** Serialization initialisation
What exactly makes the output serialization process start in the current
implementation? I've been unable to find the spot...






Well, the good news is that I've figured out the last few problems with the
new serialization scheme. Atleast in theory.