Re: A little more exact specification of the hash-table

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>Yes. I think it would then perhaps be beneficial to simply handle format 1
>writing without implicating the container at all. See below.

Right.

>>Nope. Write on access.
>>
>Then the "ppfAddFile()" or whatever function is used for that can update the
>pak. This way, the container only needs to serialize to format 0. It'll need
>to serialize FROM a whole array of sources, but that's not that big a
>problem.
>
>Btw, I think the class that keeps track of files (ppf_File?), and the one
>for dirs, should have a member WriteToStream(). The naming isn't important,

That's what I wrote the ppf_PakFileW* classes for. ppf_PakFileWDir has
about the same code size as ppf_PakFileDir and only  about 10 lines are the
same (almost all inline accessor methods)

>of course. The point is that the file/dir class itself should know how to
>serialize itself, thus removing the dependency of, to the file/dir class,
                                                ^^^^^^^^^
?-(

>external code being dependent on that file/dir class' data can simply be
>dumped to the file. Code external to the file/dir class doesn't care exactly
>how the file class is serialized, it just wants it to be.

>I still think having two seperate containers for dirs and files are by far
>the best implementation. This could all be done internally to the container
>class, so the rest of PPlay wouldn't have to know. We'd be saving memory

>Keeping the arrays seperate has only one, single, drawback: if it isn't
>know wheter a path is a file or dir, you have to look in both tables,
>doubling look-up time. However, I think this is largely inconsequential,
>since only files can be the last part of a path (you can't open or write
>to directories), and only directories can be the first part(s) of a

Wrong. ppfOpenDir () does exactly this. But 

>path. I just don't see a case where you wouldn't know wheter its a
>directory or a file you're looking for, and even then, lookups ARE

ppfStat () and ppfCopy () both are such cases, but you're right.

>extremely fast. I remember you being against this with trees, though I
>can't remember why. 

Because with the tree iteration over all entries guaranteed alphabetical
order, and having seperate containers for files and dirs would have
destroyed that. But with hashing we don't have that kind of sorting anyway,
so it's ok now.


>btw, if we are going to do serializing, should I implement it using a
>standard library file-handle, a PFile file handle or a standrad library

cstdio FILE

>stream class? I'd go for a PFile file-handle. Else it would be impossible to
>write to any alternative file systems.

You can't read Paks from alternative file systems anyway, because that
would mean an overhead for reading in all cases, whether the Pak is in a
nonstandard FS or not (ppfRead (file in Pak) would have to call ppfRead
(PakFile), each time analyzing the fstype etc). And usually you *do* have
the Pak in the normal FS (I don't see any reasons for having it elsewhere).


	Christian
-- 

Drive A: not responding...Formatting C: instead