[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Funny situation (was: Re: Serialization et al)
(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
* 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
>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
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
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
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
Drive A: not responding...Formatting C: instead