Table 21 in TR1 defines the semantics of b.load_factor() this way:

   Returns the average number of elements per bucket.

Is there a reason it doesn't do it more like this?

   Returns float(b.size())/b.bucket_count()

Thanks,

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <121ojo3t096da26@corp.supernews.com>,
 usenet@aristeia.com (Scott Meyers) wrote:

> Table 21 in TR1 defines the semantics of b.load_factor() this way:
>
>    Returns the average number of elements per bucket.
>
> Is there a reason it doesn't do it more like this?
>
>    Returns float(b.size())/b.bucket_count()

The LWG has developed an allergy to specifying algorithms.  That isn't
to say that we still don't.  But when it is easy to state what we want,
instead of how we want it computed, it has become much preferable to do
the former.  We've been bitten more than once by doing the latter only
to have the algorithm turn up flawed.

For example the container requirements currently state (much to my
dismay) that b.size() should have constant complexity.  In plain English
that means, it might have constant complexity, and it might not
(vendor's choice).  size() could have linear, quadratic, or even
exponential complexity.  By stating what we want, and what complexity it
should have, instead of an algorithm, the effects are nailed down much
tighter, and made more immune to remote edits of other parts of the
document.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]