Re: [Boost-users] [filesystem] function to determine available space

From: Daniel Krügler (dsp_at_[hidden])
Date: 2005-09-15 06:37:34

Hello Beman Dawes,

Beman Dawes wrote:
> "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message 
> news:dg4gv5$mji$1_at_sea.gmane.org...
> 
>>"Beman Dawes" wrote:
>>
>>
>>>I'm planning to add a filesystem function to determine available disk 
>>>space. Perhaps something like:
>>>
>>>struct space_status
>>>{
>>> boost::uintmax_t  available;  // free space available to user
>>> boost::uintmax_t  total;        // total space on volume
>>>};
>>>
>>>space_status filesystem_space( const path & p );
>>>
>>
>>The single uintmax_t may not be able to capture
>>all those free gigabytes. Better use two values.
> 
> 
> Hum... Are there any systems anymore that support disk drives that don't 
> have 64-bit uintmax_t?

Although I don't see **currently** a problem with usual uintmax_t 
definitions, I have a more defensive view on this:

It has happend in history that hardware development has been
quicker than software development and it was not unusual that suddenly
a system needed to replace their "atomic" type used representation of
system related properties (e.g. address space of memory) by means of
a "conglomerated" type with internal logic to handle this situation.

This might happen quicker than we believe if a sudden technological jump 
invalidates current interpolations of disk-sizes.

A safer method would be to provide a simple type(def), e.g.

disk_size_t

with some described operations which are guaranteed to be provided (at 
least EqualityComparable and LessComparable ;-)). This makes it easier
to handle special OPs and costs nothing, if in the moment its simply a 
typedef to uintmax_t.

Just my 0.02 Euro cent

Daniel Krügler