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

[Pierre Phaneuf <pp@ludusdesign.com>]

Bjarke Hammersholt Roune wrote:

> > You had a good start in that implementation, I just didn't have enough
> > time to completely cover it this time. Some things were still off-base.
> 
> My english isn't perfect. Off-base means ... ? Sub optimal?

Means missing the target, missing the goal (not by not going far enough,
but by straying from it). I think this comes from baseball.

> > I don't exactly see why it is a template. The entries should be
> > abstracted as well, so no need to make this class generic, it will take
> > entries of the abstract class.
> 
> You lost me here. It will take entries of the abstract class? You mean
> like it will "take" (i.e., contain) the abstract class for a file or a
> directory? If you do, then, that's possible within the scheme.
> 
> The reason the FileSystemEntityContainer is a template, is that there
> are two basic kinds of file system entities (i.e., dirs and files), and
> these two are kept separately in two *different* containers.

Why not a single container? This is a case of the composite container (I
think this is the name, not sure) pattern. This pattern is for cases
where you have a tree of items where nodes and leaves share a lot of
functionality (nodes would be directory and leaves would be files, and
they are almost the same). You simply make the node class inherit the
leave class and have the pointer to the root of the tree be a pointer to
a leave. The node class would add a few content manipulation methods
(addEntry, removeEntry) and whatever else is specific to the node.

> Of course, it would be possible to devise an interface and
> implementation for FileSystemEntityContainer that would make it possible
> for it to meet the requirements of both being a container for dirs and
> files, without being a template. However, that would require
> compromising compile time type safety in favor of runtime type safety.
> This is bad both in terms of efficiency and bug tracking.
> 
> FileSystemEntityContainer being a template isn't all that bad, as we'll
> probably only be making two different instantiations of it (one for
> File, and one for Directory).

It isn't that bad. Correct me if I'm wrong, but that means a file
container won't be able to contain directories and vice-versa? And
FileSystemEntityContainer isn't a directory itself? Consider this:

class File {
public:
  int open(...);
  [ other File methods ]
};

class Directory: public File {
public:
  [ implementation of inherited methods from File ]
  int addEntry(File*);
  int removeEntry(File*);
};

This makes for one simple system. There could be a asDirectory() method
to get a properly casted Directory* or a NULL if the File is really only
a File (similar to the S_ISDIR macro applied to the POSIX structure
equivalent to those classes, struct stat). Or dynamic_cast could be
used.

Also, File and Directory themselves would only be abstract classes. File
would have UnixFile, PakFile, ZipFile, and whatever else as childrens.
Note that I blatantly reused the "PakFile" name for a different class,
this clash would have to be fixed. The same would be done for
directories. The UnixFile and UnixDirectory classes would be implemented
as a cache of what is actually on disk (because populating a whole tree
of those for files on the filesystem would be both useless and very
expensive). When you'd mount a Pak file, it would deserialize its tree
of PakDirectory and PakFile (from its table of content) and hang it at
the appropriate place in the tree.

Simple API, maps quite nicely to the underlying concepts. 10% of the
work, and easily fixable! ;-)

> > The requirement just after the
> > "FileSystemEntityContainer is a template" one is one requiring that the
> > entries should have some specific methods, this only reinforce this.
> 
> Reinforce what?

The methods required to be there.

> > There should be simply an abstract class with those methods as pure
> > virtual, simple and straightforward.
> 
> There is. FileSystemEntityContainer is both a template as well as an
> abstract base class with all pure virtual methods. The template dictates
> the interface, the pure virtual methods provide the implementation.

Yes, but can only contain one or the other of directories or file???
What, each directory would have two FileSystemEntityContainer, one for
the directories it contains and the other for the files it contains? You
call that straightforward?

> > The LISP version, if it would be translated directly in C, would be
> > recursive too, but why it is called iterative anyway is that a LISP
> > compiler is normally smart enough to transform this into an iterative.
> > C/C++ compilers don't optimize over function/method boundaries (except
> > for inline stuff, of course).
> 
> Isn't that a weakness in compilers rather than in the language of C/C++
> itself? I get the hint that its more tricky implementing this in C/C++
> (or compilers would do it), but still, I don't believe its impossible,
> just very hard.

Yes, but there are some semantic requirements defined in the C++
standard that prevents compilers from making all kinds of assumptions
that could enable safe optimizations.

My day job is in high performance computing, if I may recall you, and
most amazingly, the reason a language that sucks like Fortran is so
popular, is, err, *because* it sucks! The language is so primitive and
so restrictive, while still mostly there and programmable (it *is* a
pain in the ass, but not nearly as much as assembler, and a portable
pain in the ass furthermore), that it is extremely optimizable!

My favorite example are pointers. Say you have a function that takes two
int*. In C++, you simply cannot increment one of the int (not its
pointer, but the int it points to) and assume the other didn't change,
because they could both point to the same int! There is no such thing as
pointers in Fortran, so compilers are free to assume one of the
parameters is an invariant thru a loop and avoid doing any costly
refetchs.

Even the best C/C++ compilers, like Kai's or Compaq's (previously
Digital) can't approach the level of performance many Fortran compilers
can do. By the way, GCC/EGCS is not there at all when it comes to high
performance computing (not enough support for things like vectors and
specialized architectures and instructions).

> I've noticed that when people really are trying to be rude over E-mail,
> it'll be so blatantly obvious that its completely impossible to miss. It
> usually goes something like "You suck", "man, you're a retard" or
> "You're dumb as a door".

Yeah, that's a pretty good sign. :-)

-- 
Pierre Phaneuf
http://ludusdesign.com/