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

[Christian Reiniger <warewolf@mayn.de>]

(actually a "reply" to Pierre)

Bjarke Hammersholt Roune wrote:
>> It just seems so simple and straightforward to me:
>> 
>>  - a directory contains files.
>>  - a directory is a file.

I like this too, somehow. But it doesn't really make much sense. Here's my
distinction:

* A Directory is a file system entity that can contain other FS entities
* All other FS entities are files

Or what about this:

* A File is something calling ppfRead () upon makes sense
* A Directory is something calling ppfRead () upon does *not* make sense

Both cover the case with named pipes, sockets, procfs files etcetc

>> The asDirectory() method is an intermediate way of doing this: it is
>> static, as you can't do asDirectory() on just about any object to ask it
>> if it is a directory, but it let you have the dynamic advantages of
>> dynamic_cast.
>>
>It *is* RTTI. It's not static in the way Bjarne meant it: He was talking
>about compile-time checked type safety. This quite clearly is not what
>AsDirectory() does.

I can't resist seconding that :)

>> I am suggesting moving the iteration and container interface to
>> Directory. Internally, something like FileSystemEntityContainer could be
>> used, but they would be specific to the Directory derivative, I do not
>> care about how they actually do that.
>>
>I believe there are already several iterators to iterate over all the
>members of a Directory. Actually, I think I've implemented const and
>non-const versions of these for iterating over files, sub-directories
>and both.

Yes. ppfOpenDir () & Co use those.

>> I knew it was used and "blatantly reused" the name because deep inside,
>> I'd like PakFile to be called PakArchive. Just ignore me. :-)
>>
>Hmm... I actually like that. The part about PakArchive (not the ignore
>stuff :).

Hmmm, basically ok. I just don't like that "PakArchive" is longer than
"PakFile". What about just "Pak" (and "Zip" and "Tar" and ...)?

>like having std::vector<T> derive from its template argument. It just
>doesn't compute. Atleast not for me. container<->data. A collection of
>something is quite different from just one of something.

Sometimes it makes sense (the example in the "Patterns" book are "glyphs"
in a graphical editor, which can be single chars or inline gfx or words or
lines or paragraphs etc). But not here.

>According to an article I saw on LGDC MS's compiler severely outperforms
>the GNU compilers, and it was the quickest in the test. Unless my memory
>has completely failed me, that is. The article migth be a bit dated,
>though (not sure).

It is. But it's basically right. Really good optimization for gcc is just
now coming.


	Christian
-- 

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