[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SV: Directory

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).


>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

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.


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