Re: Funny situation (was: Re: Serialization et al)

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>However, your idea is/was to make derivatives of HashTable. Thus,

is.

>HashTable still only knows how to serialize itself in a way that makes
>sense relative to itself, but its derivative class ZipHashTable will
>also be able to serialize Zip files. The reason this is IMHO still
>appripiate is that the Zip format makes sense relative to ZipHashTable.

>For now, though, I woudln't recommend doing the changes nessecary to
>implement this new solution. Let's get something working first.

Correct. Here's the plan:

I'll implement the PakFiles-are-made-up-of-parts thing, adapt the other
code (incl. serialization) to that, make sure the PakFile* classes work as
expected (attribute checking etc), adapt the Serialization code to add item
IDs ("dir\0") and to "unroll" the directory save recursion.

In the meantime you implement Win32.cpp

After that the thing should be really ready for testing & bug fixing. And
CVSing.

*After* the 0.1 release we'll implement the structural changes discussed in
this thread.

>> It calculates the faculty of n
>> Our Prof presented this as example of an "iterative" process (meaning that
>> a compiler can optimize it to an iterative process) ;)
>> The recursive version is:

>I've just desided I don't like LISP :)
>
>C++ is so superior to that.

Don't decide too fast. The code is not a typical example for LISP code, but
a typical example for purely functional code. LISP isn't *that* bad.
I can't stand it anyway ;)

>That other solution I mentioned above:
>
>We have a pure virtual baseclass. Let's call it
>FileSystemEntityContainer. The name might need a bit of shortening, but
>otherwise, it should be ok.

template <...> FSEntityContainer
typedef FSEntityContainer<File *> FileContainer
typedef FSEntityContainer<Directory *> DirContainer

>implemented as a collection). It has template parameters that specify
>what kind of entries it will be storing aswell as what kind of key it
>will accept when searching for suchs an entry. That's it. No MISC.

Very good. The "kind of key" can be left out as well. All FS Entities
have a String key.

>FileSystemEntityContainer requires that classes used as the entry-type
>parameter must declare these methods:
>
>key-type GetKey() const
>entry-type& operator=(const entry-type&)
>entry-type()

>entry-type(&entry-type&)

???? Copy constructor ????

>If serialization is also intended, these additional methods must also be
>present:
>
>bool SerializeTo(FILE*) const
>bool SerializeFrom(FILE*)

bool Serialize ()
bool Deserialize ()

The derivations usually know where to serialize themselves to. An
alternative would be to keep the FILE * argument and simply ignore it where
it makes sense. Dunno.

>FileSystemEntityContainer requires that classes used as the key-type
>parameter must declare these methods:
>
>bool operator==(const key-type&) const
>bool operator>(const key-type&) const

Why? Comparison is a virtual method anyway.

>Directory will store its contained files and directories in
>FileSystemEntityContainers. These containers are created in the
>constructors of Directory's derivatives. This eliminates the need for
>virtual factory methods, at no inconvinience or cost, which we would

Well, it requires that the derived class has free access to the Directory
data members. A factory method avoids this.

>Both A) and B) are supported by good arguments, and are good solutions.
>Actually, they are both so good that I don't think its appropiate to say
>that one will clearly be the better solution in all cases. I think the
>best way to do this would be to say that, well, the answer to the
>question "What is the most appropiate solution?" is: "It depends."

Agreed.


	Christian
-- 

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