Re: [boost] [Filesystem V3] file_status over-design?

Subject: Re: [boost] [Filesystem V3] file_status over-design?
From: Darryl Green (darryl.green_at_[hidden])
Date: 2010-02-27 08:37:59

On Tue, 2010-02-23 at 20:15 -0500, Beman Dawes wrote:
> On Tue, Feb 23, 2010 at 8:53 AM, Edward Diener <eldiener_at_[hidden]> wrote:
> ...
> >> The fix would be to rename the enum as file_status, and remove the
> >> current class file_status entirely. That would break a certain amount
> >> of existing code, but I suspect the C++ committee would force such a
> >> change anyhow for TR2, so better to get it over with now.
> >>
> >> Comments? Opinions?
> >
> > Keep the status() function but add a filetype() function which returns a
> > file_type enumerated value.
> 
> Hum... That would ease the transition. It has also gotten me thinking
> about other ways to minimize breakage of existing code. More later.
> 

fwiw (I haven't used filesystem so far) in a similar in-house lib we
found it necessary to make the "stat" object caching and lazy. This has
problems of its own, but the problem with doing otherwise is that
collecting all file status info may be quite expensive (and
additionally, which info is expensive to collect may be platform
dependent). Further, making repeated calls to "stat" or its ilk should
be avoided where possible for the same performance reasons.

However, I think providing a few small/specific interfaces is a
reasonable idea for ease of use without too big a performance hit in
common/simple cases.

So - I agree with providing filetype(), which complements size(),
last_write_time() and the is_xxx() interfaces for obtaining specific
dimensions of file information. I would further suggest that status()
should/could eventually "evolve" to return a lazy/caching status object,
but backwards compatibility is all that matters for now. Such an object
should eventually provide the same set of information as the various
functions that provide information via a similar interface, with the
proviso that the result returned may reflect the state of the filesystem
object referenced by path as it was at any time between when
status(path) was called and when the corresponding accessor member
function of the returned file_status object was called. This won't break
existing code so long as the filetype info at least is retrieved
early.It would seem trivial to extend it now to include at least the
information / interfaces size() last_write_time(), is_xxx() where in the
posix impl at least (and perhaps others for simplicity) all info would
be obtained on the call to status().

regards
Darryl.