On 15/09/05, Daniel Krügler
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
Note that this issue is also handled elegantly by the double option, perhaps more so, because if suddenly you install a YottaByte drive, you'll just lose precision--no recompiling would be necessary. Some further numbers about the double precision: Using the 24-bit mantissa floats, that means +/- 16 KB for a 16 GB measurement, or +/- 16 MB on a 16 TB measurement. For the 53-bit mantissa double, that same 16-TB measurement could be accurate to +/-0.001953125 bytes :P The one drawback would be that summing entries could be victim to round-off error, of course. Once at that 16 GB mark with the 24-bit floats, no matter how many 4 KB amounts you add, the number wont change. I'd argue that this oughtn't be too much of an issue, since it seems as though the lib is concerned with free, used, and total space of a path::root() and not with individual files. Perhaps, however, it should also provide that information for arbitrary paths for which is_directory returns true, although I don't think it would be possible to provide any meaningful performance guarantees if that path is not just a root. Scott McMurray