Boost logo

Boost :

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2005-05-09 20:08:07

> >> > 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:
> >
> > FreeBSD and Solaris both allow opening a directory (read-only) with
> > open(2) and reading from it with read(2) on their default FS types.
> >
> > If you know the format of the directory and want to write a non-portable
> > app that reads it directly you could use an ifstream to do so, in
> > theory.
> Sure, but it seems like you can only use that facility on a system you
> already have prior knowledge about. Part of that knowledge could come from
> ::stat(), either directly or wrapped in a call to
> boost::filesystem::status().

Yes that knowledge _could_ come from status(), but for platforms that dont support the named property, the implementation should return something useful as a fallback.

However, is_blah() should "do the right thing" on platforms which dont support 'blah'

> But if stat() doesn't report both S_ISDIR and S_ISREG true at the same time,
> there isn't any way to practically implement status(), even if you buy the
> argument that reporting both would be desirable.

sure there is... dont use stat() - use boost::filesystem::status() then have status() return something that generic code can work with. And the return code from status() doesn't _have to_ be the actual bitmap value returned from S_ISDIR && S_ISREG -> status() can choose to remap this return value into something platform agnostic.

If a developer chooses to use stat() - which is not always platform agnostic - thats their own fault. One purpose of using boost::filesystem is to abstract the platform inconsitancies.


Boost list run by bdawes at, gregod at, cpdaniel at, john at