From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-13 08:20:19
From: "Beman Dawes" <bdawes_at_[hidden]>
> I'm planning to add a filesystem function to determine available disk space.
> Perhaps something like:
> struct space
> boost::uintmax_t available; // bytes available to user
> boost::uintmax_t total; // total bytes on volume
> space filesystem_space( const path & p );
As previously mentioned, the "filesystem_" prefix is redundant.
Also, I wonder about the value of returning both values
simultaneously. I don't expect that all platforms, if any do,
provide both values in a single API call. Thus, your one call
would frequently result in multiple API calls, in my
imagination. I'll grant you that your function wouldn't be
called with high frequency, so that's not too much of a concern.
I propose this interface:
boost::uintmax_t free_space(path const &);
boost::uintmax_t capacity(path const &);
That leaves open the possibility of additional queries in the
future without having to change the return type. Also, the
return type could grow too large to like returning it by value,
so you might wind up changing the interface altogether when the
space type grows too large.
Another approach is to create a device type that can provide
member functions to query a variety of attributes. There could
even be a hierarchy of types. Since this kind of information
isn't queried with high frequency, there shouldn't be any
complaints about virtual functions, for example.
The hierarchy would permit derivates to encapsulate the logic
that no doubt differs for the various devices one would like to
query. Windows probably uses a different API for every kind of
device, for example.
So, I'm thinking of something like the following list of types:
disk : device
hard_disk : disk
floppy_disk : disk
network_disk : disk
usb_drive : device
pccard : device
Whether all of those (or any, for that matter) are needed is
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk