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

SV: Directory



>>The situation is exactly the same for SearchFile(), SearchDir() and
>>SearchEntry(), except that what is taken is a "const URLInfo&", and there
is
>>only one overload of each. All the SearchXxx and GetXxx methods uses
>>iteration rather than recursion.
>
>In SearchXXX also iteration as in [...SNIP...] ?

Recursion like in the code exceprt at the end of this Email.

>IsEmpty () is used for determining whether the the dir can be removed
>safely. That's only done during the preparations for mounting and
umounting.
>
>>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
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).

>In 99.99% of the cases it would either (1) immediately find a file or (2)
>almost immediately find a dir that's attached to a mounted FS (and thus
>cannot be safely removed) or (3) recurse into the one or perhaps (very
>rare!) two directories that are the only entries in this dir.
>
Ok

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

>>I remove the GetFirstEntry() and ContainsDir(). I've implemented an
external
>>iterator to replace GetFirstEntry(). That's what its used for, rigth,
>
>Right. Used in ppf_OpenDir () and ppf_PakFileWDir::Cleanup ()
>
I'll fix those.

>>SetParent() has been changed so that its single Directory pointer
parameter
>>cannot be 0. The functionality previously given by calling SetParent() has
>>been moved into MakeTopMostDir(). The method IsTopMostDir() has been
added.
>
>MakeTopMostDir () is unneccessary. There is only one topmost dir, and that
>is created during initialization of the global object ppf_GlobalData, with
>parent=0 in the constructor.
>
I don't think its too obvious what "Directory m_dir(0)" means. With
"Directory m_dir; m_dir.MakeTopMostDir()" there would be no doubt.

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

>>I haven't got to serializing yet. I think it would perhaps be a good idea
to
>>define virtual methods SerializeFrom(FILE*) and SerializeTo(FILE*) in
>>Directory... ? Else we have all serializing functionality stuck in Misc
>>(which isn't very intuitive), and we can't expand upon it in derivatives
of
>>Directory.
>
>Agreed. But I don't know if a simple SerializeTo () will work. Hmm, Pak F1
>updating isn't done via serialize anyway, so it should be ok.
>
Actually, there'll need to be two seperate serialization methods. One that
serializes the info that is contained in the dir, and one that serializes
the content of the files contained in the dir. And two more for the reverse
process, of course.

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

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.

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.

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

>I completely removed the #include <unistd.h> thing from the headers.
>Instead a symbol PP_SYS_POSIX is defined (or not...)
>
Nice.

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?

--

And the code I mentioned ealier on what I meant by "iteration":

File* Directory::SearchFile(const URLInfo& URL,
	int startIndex) throw()
{
	Directory* pCurrDir  = this;
	int subPartCount = URL.GetPartCount() - 1;

	while (startIndex < subPartCount)
	{
		pCurrDir = pCurrDir->GetDir(
			URL.GetPartStart(startIndex),
			URL.GetPartSize(startIndex));

		if (pCurrDir == 0)
			return 0;

		++startIndex;
	}

	return GetFile(
			URL.GetPartStart(startIndex),
			URL.GetPartSize(startIndex));
}