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

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger 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

You cheat here. The first rule is actually *two*:

 - a directory is a file system entity
 - a directory can contain file system entities

If I were ruthless, I'd say that this is 50% more complex, not even
counting the fact that two rules describing a single item (directories)
makes for additionnal complexity due to possible conflicts (they do not
happen in this case, but this is "opening the door").

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

Hmm... Making sense is rather subjective for a "rule"... *I* think that
using dynamic_cast makes sense and is not evil at all, does that make me
right? What *I* think is evil is that compiler support and
implementation of dynamic_cast is spotty.

> > > 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 defined my use of "RTTI" further in some other post... Heck, if
checking everything at compile-time was possible, we wouldn't have
programs, we'd only have compilers that would directly gives us
*results*! :-)

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

Not that long (three letters) and consider this is only used at
declaration time (as in "PakArchive* pak;", it is "pak" that you use all
the time, not "PakArchive"). Just the three letters is running after
trouble, IMHO...

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

Yes, as they progressively include improvements from PGCC and other
similar projects, it gets better and better. BTW, any info on how PGCC
compares with VC++?

Anyway, those are small margins, compiling with gcc/egcs at maximum
optimization still makes a lot of sense and isn't that bad.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi