"Rob Stewart" <stewart@sig.com> wrote in message news:200509131320.j8DDKJ8K031913@shannonhoon.balstatdev.susq.com...
From: "Beman Dawes" <bdawes@acm.org>
I'm planning to add a filesystem function to determine available disk space.
Great!
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.
Yep. The implementation (committed to CVS branch i18n yesterday) uses space().
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 &);
Interesting. Windows and POSIX supply the result via a single call. But other systems might have separate calls. Separate functions are a bit easier to specify.
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.
Excellent points.
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:
device disk : device hard_disk : disk floppy_disk : disk network_disk : disk usb_drive : device pccard : device etc.
Whether all of those (or any, for that matter) are needed is debatable.
While we've often talked about a more flexible way to deal with attributes, particularly operating system specific attributes, I've not yet been convince any proposed scheme is worth the effort. I'll give your suggestion regarding separate free_space() and capacity() functions some more thought tomorrow morning when my mind is functioning a bit better than it does at night (Of all the things I've ever lost, I miss my mind the most:-) --Beman