Re: SV: Directory

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>In SearchXXX also iteration as in [...SNIP...] ?
>
>Recursion like in the code exceprt at the end of this Email.

I.e. iteration. Ok.

>>>I think the new names for IsEmpty() and IsPseudoEmpty() portrays somewhat
>>>better what exactly is going on. IsPseudoEmpty() clearly tells people that
>>>even if it returns true, things are only "kind of empty".
>>
>>But it doesn't matter ;)
>At some point in the future, someone migth use
>IsEmpty() for another porpuse. He most probably ewon't look up the docs for
                       ^^^^^^^
At least you're consequent at misspelling that ;)

>suchs a function, as the functionality of ItEmpty() should be rather
>obvious. He'll get a surprise or a bug (if he doesn't find out).

Agreed.

>What exactly do you mean by "attached to a mounted FS" ?  Like part of pak
>that is mounted?

Yup. In contrast to a GenericDir that only exists to "fill the path".

>>On the other hand - the "parent" item in the constructor could be
>>obsoleted. SetParent () is called anyway in Directory::Insert ()
>>
>Hmm... Your right about that. I'll remove it and fix ppf_GlobalData (unless
>you mind?).

Having too many arguments in a function is bad anyway. (that means, no, I
certainly don't mind)

>I think I'll make SerializeTo() non-virtual and make it call the two virtual
>methods.

Sounds good. That makes for an easier interface and makes it easier to
adapt to other filesystems where serializing could be written in only one
pass or so.

>I was wondering, can I count on ALL dirs to store their data in a HashTable
>for dirs and one for files? That way I can do some optimizations.

Only the Directory class is storing things, right?

>On another note, we'll need to store the length of the filename of files in
>the File class. I can make things work without this, but it'd be a big mess.

No problem.

>Oh yeah, and another thing. The File class will also need the virtual
>SerializeTo() and SerializeFrom() methods.

Of course ;)

>I was wondering wheter or not it would be a good idea to define a symbol
>that identifies the compiler being compiled on. Like a PP_COMPILER_GCC or
>PP_COMPILER_MSVC and then the value of that symbol would be the version
>number. What do you think of that?

I thought about that too, but steering clear of compiler specific things is
much better.


	Christian
-- 

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