Topic: Remove floating point requirement for unordered
Author: kfitch42@gmail.com
Date: Tue, 27 Mar 2018 09:06:39 -0700 (PDT)
Raw View
------=_Part_18658_639999995.1522166799010
Content-Type: multipart/alternative;
boundary="----=_Part_18659_1429057989.1522166799011"
------=_Part_18659_1429057989.1522166799011
Content-Type: text/plain; charset="UTF-8"
The current interface for dealing with load factor with in unordered
containers is one of the few (only?) places in the C++ standard library
where floating point is required even if you didn't "opt-in" to floating
point. E.g. see
http://en.cppreference.com/w/cpp/container/unordered_set/max_load_factor
On many embedded systems hardware floating point is unavailable, and using
software to emulate it is very expensive. Both in terms of code size and
runtime.
It should be straightforward to provide a new interface (possibly via an
overload) for max_load_factor that takes something like a fixed point
number. Potential interfaces include:
// This would be easy to understand for those reading the docs, but doesn't
leverage the type system very well
// percentage would be expected to be between 0 and 100.
void max_load_factor( int percentage );
// Or we could leverage the ratio header in a similar way to std::chrono
// A quick/dirty version could look like:
template<class Rep, class Multiplier = std::ratio<1,100> >
struct load_factor { Rep value; };
template<class Rep, intmax_t Num, intmax_t Denom>
int max_load_factor(const load_factor<Rep,std::ratio<Num,Denom>>& lf);
The interface for getting the current or max load factor would be, in some
ways, messier. I guess the functions would need new names, perhaps:
template<class Rep, intmax_t Num, intmax_t Denom>
load_factor<Rep,std::ratio<Num,Denom>> get_max_load_factor();
template<class Rep, intmax_t Num, intmax_t Denom>
load_factor<Rep,std::ratio<Num,Denom>> get_load_factor();
Please let me know what you thing . I am by no means a C++ expert, and
would love feedback on the best approach to this interface. But, my main
goal is to avoid having to deal with floating point in order to get all the
benefits of unordered containers on small/embedded systems.
Kevin Fitch
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4c98e549-8f0c-42e5-a054-0234f7cf1e46%40isocpp.org.
------=_Part_18659_1429057989.1522166799011
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The current interface for dealing with load factor with in=
unordered containers is one of the few (only?) places in the C++ standard =
library where floating point is required even if you didn't "opt-i=
n" to floating point. E.g. see http://en.cppreference.com/w/cpp/contai=
ner/unordered_set/max_load_factor<br><br>On many embedded systems hardware =
floating point is unavailable, and using software to emulate it is very exp=
ensive. Both in terms of code size and runtime.<br><br>It should be straigh=
tforward to provide a new interface (possibly via an overload) for max_load=
_factor that takes something like a fixed point number. Potential interface=
s include:<br><br>// This would be easy to understand for those reading the=
docs, but doesn't leverage the type system very well<br>// percentage =
would be expected to be between 0 and 100.<br><div><span class=3D"mw-geshi =
cpp source-cpp"><span class=3D"kw4">void</span> max_load_factor<span class=
=3D"br0">(</span> int<span class=3D"kw4"></span> percentage <span class=3D"=
br0">)</span><span class=3D"sy4">;<br><br>// Or we could leverage the ratio=
header in a similar way to std::chrono<br>// A quick/dirty version could l=
ook like:<br></span></span><div style=3D"color: #000000;background-color: #=
fffffe;font-family: Consolas, "><div><span style=3D"color: #0000ff;">templa=
te</span><span style=3D"color: #000000;"><</span><span style=3D"color: #=
0000ff;">class</span><span style=3D"color: #000000;"> Rep, </span><span sty=
le=3D"color: #0000ff;">class</span><span style=3D"color: #000000;"> Multipl=
ier =3D std::ratio<</span><span style=3D"color: #09885a;">1</span><span =
style=3D"color: #000000;">,</span><span style=3D"color: #09885a;">100</span=
><span style=3D"color: #000000;">> ></span></div><div><span style=3D"=
color: #0000ff;">struct</span><span style=3D"color: #000000;"> load_factor =
{ Rep value; };</span></div><br><div><span style=3D"color: #0000ff;">templa=
te</span><span style=3D"color: #000000;"><</span><span style=3D"color: #=
0000ff;">class</span><span style=3D"color: #000000;"> Rep, intmax_t Num, in=
tmax_t Denom></span></div><div><span style=3D"color: #0000ff;">int</span=
><span style=3D"color: #000000;"> max_load_factor(</span><span style=3D"col=
or: #0000ff;">const</span><span style=3D"color: #000000;"> load_factor<R=
ep,std::ratio<Num,Denom>>& lf);</span><br></div></div><span cl=
ass=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><br>The interface for g=
etting the current or max load factor would be, in some ways, messier. I gu=
ess the functions would need new names, perhaps:<br></span></span><div styl=
e=3D"color: #000000;background-color: #fffffe;font-family: Consolas, "><div=
><span style=3D"color: #0000ff;">template</span><span style=3D"color: #0000=
00;"><</span><span style=3D"color: #0000ff;">class</span><span style=3D"=
color: #000000;"> Rep, intmax_t Num, intmax_t Denom></span></div><div><s=
pan style=3D"color: #000000;">load_factor<Rep,std::ratio<Num,Denom>=
;> get_max_load_factor();<br><br></span><div style=3D"color: #000000;bac=
kground-color: #fffffe;font-family: Consolas, "><div><span style=3D"color: =
#0000ff;">template</span><span style=3D"color: #000000;"><</span><span s=
tyle=3D"color: #0000ff;">class</span><span style=3D"color: #000000;"> Rep, =
intmax_t Num, intmax_t Denom></span></div><div><span style=3D"color: #00=
0000;">load_factor<Rep,std::ratio<Num,Denom>> get_load_factor()=
;</span></div></div><br>Please let me know what you thing . I am by no mean=
s a C++ expert, and would love feedback on the best approach to this interf=
ace. But, my main goal is to avoid having to deal with floating point in or=
der to get all the benefits of unordered containers on small/embedded syste=
ms.<br><span style=3D"color: #000000;"></span></div></div><br>Kevin Fitch<b=
r><br><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"></span></=
span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4c98e549-8f0c-42e5-a054-0234f7cf1e46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4c98e549-8f0c-42e5-a054-0234f7cf1e46=
%40isocpp.org</a>.<br />
------=_Part_18659_1429057989.1522166799011--
------=_Part_18658_639999995.1522166799010--
.
Author: Todd Fleming <tbfleming@gmail.com>
Date: Tue, 27 Mar 2018 11:58:21 -0700 (PDT)
Raw View
------=_Part_19296_644783546.1522177101594
Content-Type: multipart/alternative;
boundary="----=_Part_19297_1809503896.1522177101595"
------=_Part_19297_1809503896.1522177101595
Content-Type: text/plain; charset="UTF-8"
On Tuesday, March 27, 2018 at 12:06:39 PM UTC-4, Kevin Fitch wrote:
>
> The current interface for dealing with load factor with in unordered
> containers is one of the few (only?) places in the C++ standard library
> where floating point is required even if you didn't "opt-in" to floating
> point. E.g. see
> http://en.cppreference.com/w/cpp/container/unordered_set/max_load_factor
>
> On many embedded systems hardware floating point is unavailable, and using
> software to emulate it is very expensive. Both in terms of code size and
> runtime.
>
> It should be straightforward to provide a new interface (possibly via an
> overload) for max_load_factor that takes something like a fixed point
> number. Potential interfaces include:
>
> // This would be easy to understand for those reading the docs, but
> doesn't leverage the type system very well
> // percentage would be expected to be between 0 and 100.
> void max_load_factor( int percentage );
>
> // Or we could leverage the ratio header in a similar way to std::chrono
> // A quick/dirty version could look like:
> template<class Rep, class Multiplier = std::ratio<1,100> >
> struct load_factor { Rep value; };
>
> template<class Rep, intmax_t Num, intmax_t Denom>
> int max_load_factor(const load_factor<Rep,std::ratio<Num,Denom>>& lf);
>
> The interface for getting the current or max load factor would be, in some
> ways, messier. I guess the functions would need new names, perhaps:
> template<class Rep, intmax_t Num, intmax_t Denom>
> load_factor<Rep,std::ratio<Num,Denom>> get_max_load_factor();
>
> template<class Rep, intmax_t Num, intmax_t Denom>
> load_factor<Rep,std::ratio<Num,Denom>> get_load_factor();
>
> Please let me know what you thing . I am by no means a C++ expert, and
> would love feedback on the best approach to this interface. But, my main
> goal is to avoid having to deal with floating point in order to get all the
> benefits of unordered containers on small/embedded systems.
>
> Kevin Fitch
>
If you're dealing with an embedded processor without floating point, then
chances are you're doing real-time work, which means no heap allocations
after startup. The unordered containers don't fit this.
Todd
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3dcffdf5-ea1a-41bf-87ab-1c1ddae52404%40isocpp.org.
------=_Part_19297_1809503896.1522177101595
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 27, 2018 at 12:06:39 PM UTC-4, Kevin Fit=
ch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The =
current interface for dealing with load factor with in unordered containers=
is one of the few (only?) places in the C++ standard library where floatin=
g point is required even if you didn't "opt-in" to floating p=
oint. E.g. see <a href=3D"http://en.cppreference.com/w/cpp/container/unorde=
red_set/max_load_factor" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreferenc=
e.com%2Fw%2Fcpp%2Fcontainer%2Funordered_set%2Fmax_load_factor\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNGlelACBwt-yqMV-yg2KEnqzVA0yg';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.=
cppreference.com%2Fw%2Fcpp%2Fcontainer%2Funordered_set%2Fmax_load_factor\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlelACBwt-yqMV-yg2KEnqzVA0yg';ret=
urn true;">http://en.cppreference.com/w/<wbr>cpp/container/unordered_set/<w=
br>max_load_factor</a><br><br>On many embedded systems hardware floating po=
int is unavailable, and using software to emulate it is very expensive. Bot=
h in terms of code size and runtime.<br><br>It should be straightforward to=
provide a new interface (possibly via an overload) for max_load_factor tha=
t takes something like a fixed point number. Potential interfaces include:<=
br><br>// This would be easy to understand for those reading the docs, but =
doesn't leverage the type system very well<br>// percentage would be ex=
pected to be between 0 and 100.<br><div><span><span>void</span> max_load_fa=
ctor<span>(</span> int<span></span> percentage <span>)</span><span>;<br><br=
>// Or we could leverage the ratio header in a similar way to std::chrono<b=
r>// A quick/dirty version could look like:<br></span></span><div><div><spa=
n style=3D"color:#0000ff">template</span><span style=3D"color:#000000"><=
</span><span style=3D"color:#0000ff">class</span><span style=3D"color:#0000=
00"> Rep, </span><span style=3D"color:#0000ff">class</span><span style=3D"c=
olor:#000000"> Multiplier =3D std::ratio<</span><span style=3D"color:#09=
885a">1</span><span style=3D"color:#000000">,</span><span style=3D"color:#0=
9885a">100</span><span style=3D"color:#000000">> ></span></div><div><=
span style=3D"color:#0000ff">struct</span><span style=3D"color:#000000"> lo=
ad_factor { Rep value; };</span></div><br><div><span style=3D"color:#0000ff=
">template</span><span style=3D"color:#000000"><</span><span style=3D"co=
lor:#0000ff">class</span><span style=3D"color:#000000"> Rep, intmax_t Num, =
intmax_t Denom></span></div><div><span style=3D"color:#0000ff">int</span=
><span style=3D"color:#000000"> max_load_factor(</span><span style=3D"color=
:#0000ff">const</span><span style=3D"color:#000000"> load_factor<Rep,std=
::ratio<<wbr>Num,Denom>>& lf);</span><br></div></div><span><sp=
an><br>The interface for getting the current or max load factor would be, i=
n some ways, messier. I guess the functions would need new names, perhaps:<=
br></span></span><div><div><span style=3D"color:#0000ff">template</span><sp=
an style=3D"color:#000000"><</span><span style=3D"color:#0000ff">class</=
span><span style=3D"color:#000000"> Rep, intmax_t Num, intmax_t Denom></=
span></div><div><span style=3D"color:#000000">load_factor<Rep,std::ratio=
<<wbr>Num,Denom>> get_max_load_factor();<br><br></span><div><div><=
span style=3D"color:#0000ff">template</span><span style=3D"color:#000000">&=
lt;</span><span style=3D"color:#0000ff">class</span><span style=3D"color:#0=
00000"> Rep, intmax_t Num, intmax_t Denom></span></div><div><span style=
=3D"color:#000000">load_factor<Rep,std::ratio<<wbr>Num,Denom>> =
get_load_factor();</span></div></div><br>Please let me know what you thing =
.. I am by no means a C++ expert, and would love feedback on the best approa=
ch to this interface. But, my main goal is to avoid having to deal with flo=
ating point in order to get all the benefits of unordered containers on sma=
ll/embedded systems.<br><span style=3D"color:#000000"></span></div></div><b=
r>Kevin Fitch<br></div></div></blockquote><div><br></div><div>If you're=
dealing with an embedded processor without floating point, then chances ar=
e you're doing real-time work, which means no heap allocations after st=
artup. The unordered containers don't fit this.</div><div><br></div><di=
v>Todd</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3dcffdf5-ea1a-41bf-87ab-1c1ddae52404%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3dcffdf5-ea1a-41bf-87ab-1c1ddae52404=
%40isocpp.org</a>.<br />
------=_Part_19297_1809503896.1522177101595--
------=_Part_19296_644783546.1522177101594--
.
Author: Ross Smith <ross.smith@otoy.com>
Date: Wed, 28 Mar 2018 09:36:38 +1300
Raw View
On 2018-03-28 05:06, kfitch42@gmail.com wrote:
> The current interface for dealing with load factor with in unordered
> containers is one of the few (only?) places in the C++ standard library
> where floating point is required even if you didn't "opt-in" to floating
> point.
There's at least one other place where floating point is required when
it shouldn't strictly be necessary: the probability argument to the
constructor of std::bernoulli_distribution. That one has caused me a
bit of irritation now and then; it's not that it's any kind of real
hardship, it just feels inelegant to be forced to introduce FP
approximations into code that otherwise deals entirely in integers.
Logically the long term solution to these situations should be some
kind of std::rational class. Which probably implies first adding
arbitrary precision integers, because fixed size rationals are even
more of an open invitation to unexpected overflow than fixed size
integers.
Ross Smith
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c56412a0-0078-42e7-793a-17f4feaac637%40otoy.com.
.
Author: Kevin Fitch <kfitch42@gmail.com>
Date: Tue, 27 Mar 2018 16:07:35 -0700 (PDT)
Raw View
------=_Part_19745_788213830.1522192055369
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Even when dealing with this kind of embedded real time system, where all dy=
namic allocation happens during boot, removing the need for floating point =
would be a benefit. Imagine a scenario where you initialize an unordered co=
ntainer during boot, and then use it's awesome O(1) lookup abilities are ru=
ntime. Being forced to include floating point emulation for this one usage =
could be prohibitive in terms of code space.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e4bc4267-e728-4972-8e2c-951a5655e2b4%40isocpp.or=
g.
------=_Part_19745_788213830.1522192055369--
.
Author: Kevin Fitch <kfitch42@gmail.com>
Date: Tue, 27 Mar 2018 16:09:46 -0700 (PDT)
Raw View
------=_Part_20433_293888211.1522192186609
Content-Type: text/plain; charset="UTF-8"
I would think having a templated fixed point library in the standard would solve this and be much more practical than rationals. But that is a MUCH larger proposal than this.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6d605b6-f33e-4fc3-948e-cf7c6abdc62f%40isocpp.org.
------=_Part_20433_293888211.1522192186609--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 28 Mar 2018 00:05:39 -0700 (PDT)
Raw View
------=_Part_21624_845835565.1522220739819
Content-Type: multipart/alternative;
boundary="----=_Part_21625_2078506146.1522220739819"
------=_Part_21625_2078506146.1522220739819
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno marted=C3=AC 27 marzo 2018 18:06:39 UTC+2, Kevin Fitch ha scritto=
:
>
> The current interface for dealing with load factor with in unordered=20
> containers is one of the few (only?) places in the C++ standard library=
=20
> where floating point is required even if you didn't "opt-in" to floating=
=20
> point. E.g. see=20
> http://en.cppreference.com/w/cpp/container/unordered_set/max_load_factor
>
> On many embedded systems hardware floating point is unavailable, and usin=
g=20
> software to emulate it is very expensive. Both in terms of code size and=
=20
> runtime.
>
>
This is the kind of questions you get when cppreference is your only=20
source. cppreference is usually good, but having a look at the C++ standard=
=20
wording may sometimes surprise you. Here is the description of the effect=
=20
of max_load_factor(z)
in the C++ standard (emphasis mine): "*May* change the container=E2=80=99s =
maximum=20
load factor, using z *as a hint*." This means that a conforming=20
implementation on an embedded platform has at least two ways to avoid=20
floating point computation at runtime:
1) it can just ignore all calls to max_load_factor(). Draconian, but=20
keeping a max_load_factor =3D=3D 1.0 (the default) does not require floatin=
g=20
point at all.
2) it can use the value as a hint to compute an approximate integral ratio=
=20
in max_load_factor() and store the ratio, then use the integral ratio in=20
all other places. All floating point computations would be confined in the=
=20
max_load_factor() call, which may even get inlined with no impact at=20
runtime. Even if the call is not inlined, the costs of the floating point=
=20
computations would be very limited, since the typical use-case of=20
max_load_factor() is to call it just once at initialization.=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a%40isocpp.or=
g.
------=_Part_21625_2078506146.1522220739819
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno marted=C3=AC 27 marzo 2018 18:06:39 UTC+2, Kevin=
Fitch ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">The current interface for dealing with load factor with in unordered c=
ontainers is one of the few (only?) places in the C++ standard library wher=
e floating point is required even if you didn't "opt-in" to f=
loating point. E.g. see <a href=3D"http://en.cppreference.com/w/cpp/contain=
er/unordered_set/max_load_factor" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cp=
preference.com%2Fw%2Fcpp%2Fcontainer%2Funordered_set%2Fmax_load_factor\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlelACBwt-yqMV-yg2KEnqzVA0yg';retur=
n true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A=
%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcontainer%2Funordered_set%2Fmax_load_=
factor\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlelACBwt-yqMV-yg2KEnqzVA0yg=
';return true;">http://en.cppreference.com/w/<wbr>cpp/container/unorder=
ed_set/<wbr>max_load_factor</a><br><br>On many embedded systems hardware fl=
oating point is unavailable, and using software to emulate it is very expen=
sive. Both in terms of code size and runtime.<br><br><span><span></span></s=
pan></div></blockquote><div><br>This is the kind of questions you get when =
cppreference is your only source. cppreference is usually good, but having =
a look at the C++ standard wording may sometimes surprise you. Here is the =
description of the effect of max_load_factor(z)<br> in the C++ standard (em=
phasis mine): "<b>May</b> change the container=E2=80=99s maximum load =
factor, using z <b>as a hint</b>." This means that a conforming implem=
entation on an embedded platform has at least two ways to avoid floating po=
int computation at runtime:<br>1) it can just ignore all calls to max_load_=
factor(). Draconian, but keeping a max_load_factor =3D=3D 1.0 (the default)=
does not require floating point at all.<br>2) it can use the value as a hi=
nt to compute an approximate integral ratio in max_load_factor() and store =
the ratio, then use the integral ratio in all other places. All floating po=
int computations would be confined in the max_load_factor() call, which may=
even get inlined with no impact at runtime. Even if the call is not inline=
d, the costs of the floating point computations would be very limited, sinc=
e the typical use-case of max_load_factor() is to call it just once at init=
ialization. </div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a=
%40isocpp.org</a>.<br />
------=_Part_21625_2078506146.1522220739819--
------=_Part_21624_845835565.1522220739819--
.