Boost logo

Boost Users :

From: me22 (me22.ca_at_[hidden])
Date: 2005-09-15 09:45:12


On 15/09/05, Daniel Krügler <dsp_at_[hidden]> wrote:
> 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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net