From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2005-05-08 21:05:35
> >>> A hypothetical OS that allows directories to be opened with an
> >>> ifstream may reasonably answer true to both is_stream(p) and
> >>> is_directory(p). Or maybe not. :-)
> >> I think not. Dividing the world into non-overlapping categories is
> >> much easier:-)
> > It's only easier until an example comes up that doesn't fit the scheme, so
> > you are forced to invent meta-categories (also known as "hacks" in some
> > category theory circles) such as "other". :-)
> > "Capability bits" are cleaner. Is it openable with ifstream? file_bit. Is
> > it iteratable with directory_iterator? directory_bit. Does it exist?
> > !not_found_bit.
> I'm only partially convinced. How useful is knowing that you can ifstream a
> directory? The only cases I can think of are so system specific that I have
> trouble seeing them in the context of Boost.Filesystem.
ReiserFS version 4 supports opening a directory as a file. eg:
This is so that you can treat a directory as a file, so that you can treat directory entries as 'streams' within the file (cf. win32 named file-streams).
Samba 4 is intending on using this facility to map win32 stream-open's to real POSIX file semantics.
> > When a socket is thrown your way, you just run it by the list and conclude
> > that no bit needs to be set.
> But that is about the same as having an other_flag, except that the name is
> 0 instead of other_flag. Giving it a name makes it more obvious that a
> return from status() may not have any of the other bits set
However it is implemented, it should be 'named' so that it is obvious to a person reading over the code, that the test is checking for a specific capability.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk