Topic: Remove floating point requirement for
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Tue, 27 Mar 2018 20:55:59 +0100
Raw View
--089e08268ddcc1917a05686a4840
Content-Type: text/plain; charset="UTF-8"
What *is* true is that something like std::ratio would be a *great*
alternative.
On Tue, Mar 27, 2018 at 7:58 PM, Todd Fleming <tbfleming@gmail.com> wrote:
> 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/c
>> pp/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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3dcffdf5-ea1a-41bf-87ab-1c1ddae52404%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAANG%3DkUFSXtqVre4gctWgbACtu175mYu%3DkqaGGugheQXRevt-w%40mail.gmail.com.
--089e08268ddcc1917a05686a4840
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What *is* true is that something like std::ratio would be =
a *great* alternative.</div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Tue, Mar 27, 2018 at 7:58 PM, Todd Fleming <span dir=3D"ltr">=
<<a href=3D"mailto:tbfleming@gmail.com" target=3D"_blank">tbfleming@gmai=
l.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><span class=3D"">On Tuesday, March 27, 2018 at 12:06:39 PM UTC-4, Kevin=
Fitch wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The c=
urrent 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 po=
int. E.g. see <a href=3D"http://en.cppreference.com/w/cpp/container/unorder=
ed_set/max_load_factor" rel=3D"nofollow" target=3D"_blank">http://en.cppref=
erence.com/w/c<wbr>pp/container/unordered_set/max<wbr>_load_factor</a><br><=
br>On many embedded systems hardware floating point is unavailable, and usi=
ng software to emulate it is very expensive. Both in terms of code size and=
runtime.<br><br>It should be straightforward to provide a new interface (p=
ossibly via an overload) for max_load_factor that takes something like a fi=
xed point number. Potential interfaces include:<br><br>// This would be eas=
y to understand for those reading the docs, but doesn't leverage the ty=
pe system very well<br>// percentage would be expected to be between 0 and =
100.<br><div><span><span>void</span> max_load_factor<span>(</span> int<span=
></span> percentage <span>)</span><span>;<br><br>// Or we could leverage th=
e ratio header in a similar way to std::chrono<br>// A quick/dirty version =
could look like:<br></span></span><div><div><span style=3D"color:#0000ff">t=
emplate</span><span style=3D"color:#000000"><</span><span style=3D"color=
:#0000ff">class</span><span style=3D"color:#000000"> Rep, </span><span styl=
e=3D"color:#0000ff">class</span><span style=3D"color:#000000"> Multiplier =
=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 st=
yle=3D"color:#000000">> ></span></div><div><span style=3D"color:#0000=
ff">struct</span><span style=3D"color:#000000"> load_factor { Rep value; };=
</span></div><br><div><span style=3D"color:#0000ff">template</span><span st=
yle=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:#0000ff">int</span><span style=3D"color:#00=
0000"> max_load_factor(</span><span style=3D"color:#0000ff">const</span><sp=
an style=3D"color:#000000"> load_factor<Rep,std::ratio<Num<wbr>,Denom=
>>& lf);</span><br></div></div><span><span><br>The interface for =
getting the current or max load factor would be, in some ways, messier. I g=
uess the functions would need new names, perhaps:<br></span></span><div><di=
v><span style=3D"color:#0000ff">template</span><span 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 sty=
le=3D"color:#000000">load_factor<Rep,std::ratio<Num<wbr>,Denom>>=
; get_max_load_factor();<br><br></span><div><div><span style=3D"color:#0000=
ff">template</span><span 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_fa=
ctor<Rep,std::ratio<Num<wbr>,Denom>> get_load_factor();</span><=
/div></div><br>Please let me know what you thing . I am by no means a C++ e=
xpert, 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 ge=
t all the benefits of unordered containers on small/embedded systems.<br><s=
pan style=3D"color:#000000"></span></div></div><br>Kevin Fitch<br></div></d=
iv></blockquote><div><br></div></span><div>If you're dealing with an em=
bedded processor without floating point, then chances are you're doing =
real-time work, which means no heap allocations after startup. The unordere=
d containers don't fit this.</div><div><br></div><div>Todd</div><div><b=
r></div></div><span class=3D"">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
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" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3dcf=
fdf5-ea1a-41bf-<wbr>87ab-1c1ddae52404%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></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/CAANG%3DkUFSXtqVre4gctWgbACtu175mYu%3=
DkqaGGugheQXRevt-w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUFSX=
tqVre4gctWgbACtu175mYu%3DkqaGGugheQXRevt-w%40mail.gmail.com</a>.<br />
--089e08268ddcc1917a05686a4840--
.
Author: Kevin Fitch <kfitch42@gmail.com>
Date: Wed, 28 Mar 2018 10:22:41 +0000
Raw View
--000000000000b9883505687663f3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
While a conforming implementation may jump through some hoops to minimize
the impact of the floating point requirement, the biggest problem is the
inclusion of ANY floating point. Once a floating point variable has been
declared and manipulated, the compiler needs to include software floating
point routines which can be quite large, especially by the standards of
embedded systems. Also a resource constrained embedded system is exactly
the place where you will likely need to manipulate max load factor to meet
either memory or speed requirements.
On Wed, Mar 28, 2018, 3:05 AM Alberto Barbati <albertobarbati@gmail.com>
wrote:
> Il giorno marted=C3=AC 27 marzo 2018 18:06:39 UTC+2, Kevin Fitch ha scrit=
to:
>>
>> 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 si=
ze
>> and runtime.
>>
>>
> 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++ standa=
rd
> wording may sometimes surprise you. Here is the description of the effect
> of max_load_factor(z)
> in the C++ standard (emphasis mine): "*May* change the container=E2=80=99=
s
> maximum load factor, using z *as a hint*." This means that a conforming
> implementation on an embedded platform has at least two ways to avoid
> floating point computation at runtime:
> 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 float=
ing
> point at all.
> 2) it can use the value as a hint to compute an approximate integral rati=
o
> in max_load_factor() and store the ratio, then use the integral ratio in
> all other places. All floating point computations would be confined in th=
e
> max_load_factor() call, which may even get inlined with no impact at
> runtime. Even if the call is not inlined, the costs of the floating point
> computations would be very limited, since the typical use-case of
> max_load_factor() is to call it just once at initialization.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/kGHAX6um__c/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/9d4a8ea3-9e7=
d-4851-8b28-5cd67779081a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9e=
7d-4851-8b28-5cd67779081a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAN5YuFb%2BGdsijsjbrm6xx2ASpUNpubApEeVK3MQc1y%3D=
NtV8JiQ%40mail.gmail.com.
--000000000000b9883505687663f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>While a conforming implementation may jump through s=
ome hoops to minimize the impact of the floating point requirement, the big=
gest problem is the inclusion of ANY floating point. Once a floating point =
variable has been declared and manipulated, the compiler needs to include s=
oftware floating point routines which can be quite large, especially by the=
standards of embedded systems. Also a resource constrained embedded system=
is exactly the place where you will likely need to manipulate max load fac=
tor to meet either memory or speed requirements.=C2=A0<br><br><div class=3D=
"gmail_quote"><div dir=3D"ltr">On Wed, Mar 28, 2018, 3:05 AM Alberto Barbat=
i <<a href=3D"mailto:albertobarbati@gmail.com">albertobarbati@gmail.com<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Il =
giorno marted=C3=AC 27 marzo 2018 18:06:39 UTC+2, Kevin Fitch ha scritto:<b=
lockquote 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 interfac=
e for dealing with load factor with in unordered containers is one of the f=
ew (only?) places in the C++ standard library where floating point is requi=
red even if you didn't "opt-in" to floating point. E.g. see <=
a href=3D"http://en.cppreference.com/w/cpp/container/unordered_set/max_load=
_factor" rel=3D"nofollow noreferrer" target=3D"_blank">http://en.cppreferen=
ce.com/w/cpp/container/unordered_set/max_load_factor</a><br><br>On many emb=
edded systems hardware floating point is unavailable, and using software to=
emulate it is very expensive. Both in terms of code size and runtime.<br><=
br><span><span></span></span></div></blockquote><div><br>This is the kind o=
f questions you get when cppreference is your only source. cppreference is =
usually good, but having a look at the C++ standard wording may sometimes s=
urprise you. Here is the description of the effect of max_load_factor(z)<br=
> in the C++ standard (emphasis mine): "<b>May</b> change the containe=
r=E2=80=99s maximum load factor, using z <b>as a hint</b>." This means=
that a conforming implementation on an embedded platform has at least two =
ways to avoid floating point computation at runtime:<br>1) it can just igno=
re 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 hint to compute an approximate integral ratio in max=
_load_factor() and store the ratio, then use the integral ratio in all othe=
r places. All floating point 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 inlined, the costs of the floating point computations wo=
uld be very limited, since the typical use-case of max_load_factor() is to =
call it just once at initialization. </div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/kGHAX6um__c/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/kGHAX6um__c/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank" rel=3D"n=
oreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a%40isocpp.org</a>.<br>
</blockquote></div></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/CAN5YuFb%2BGdsijsjbrm6xx2ASpUNpubApEe=
VK3MQc1y%3DNtV8JiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN5YuFb%2BGd=
sijsjbrm6xx2ASpUNpubApEeVK3MQc1y%3DNtV8JiQ%40mail.gmail.com</a>.<br />
--000000000000b9883505687663f3--
.
Author: Kevin Fitch <kfitch42@gmail.com>
Date: Wed, 28 Mar 2018 06:40:15 -0700 (PDT)
Raw View
------=_Part_22614_1095880020.1522244415132
Content-Type: multipart/alternative;
boundary="----=_Part_22615_576440381.1522244415132"
------=_Part_22615_576440381.1522244415132
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sorry for replying to myself, but I wanted to clarify a few things. First,=
=20
I think one of the greatest strengths of C++ is the philosophy of not=20
making you pay for features you don't want/need. While there are legitimate=
=20
cases for arguments along the lines of "a conforming implementation=20
could..." those need to be cognizant of reality. In particular the number=
=20
of conforming implementations is MUCH smaller than the number of=20
applications using those conforming implementations. Also, the kinds of=20
restrictions I am concerned with are more a function of the application=20
than the platform. Some users of a platform without floating point hardware=
=20
(e.g. Arduino) might see software floating point as a huge advantage (in=20
terms of things like ease of development), while others using the same chip=
=20
(e.g. the atmega 328p) might see software floating point as a nonstarter=20
due to things like code size and runtime. It should be the goal of the=20
standard to encourage implementations that can gracefully scale in multiple=
=20
dimensions (required features, code size , memory usage...) to fit the=20
needs of any given application. Adding non-floating-point methods for=20
dealing with load factor would allow conforming implementations to be=20
written such that applications that don't want to floating point, don't=20
have to use floating point.
On Wednesday, March 28, 2018 at 6:22:54 AM UTC-4, Kevin Fitch wrote:
>
> While a conforming implementation may jump through some hoops to minimize=
=20
> the impact of the floating point requirement, the biggest problem is the=
=20
> inclusion of ANY floating point. Once a floating point variable has been=
=20
> declared and manipulated, the compiler needs to include software floating=
=20
> point routines which can be quite large, especially by the standards of=
=20
> embedded systems. Also a resource constrained embedded system is exactly=
=20
> the place where you will likely need to manipulate max load factor to mee=
t=20
> either memory or speed requirements.=20
>
> On Wed, Mar 28, 2018, 3:05 AM Alberto Barbati wrote:
>
>> Il giorno marted=C3=AC 27 marzo 2018 18:06:39 UTC+2, Kevin Fitch ha scri=
tto:
>>>
>>> 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 floatin=
g=20
>>> point. E.g. see=20
>>> http://en.cppreference.com/w/cpp/container/unordered_set/max_load_facto=
r
>>>
>>> On many embedded systems hardware floating point is unavailable, and=20
>>> using software to emulate it is very expensive. Both in terms of code s=
ize=20
>>> and 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++ stand=
ard=20
>> wording may sometimes surprise you. Here is the description of the effec=
t=20
>> of max_load_factor(z)
>> in the C++ standard (emphasis mine): "*May* change the container=E2=80=
=99s=20
>> maximum 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 floa=
ting=20
>> point at all.
>> 2) it can use the value as a hint to compute an approximate integral=20
>> ratio in max_load_factor() and store the ratio, then use the integral ra=
tio=20
>> in all other places. All floating point computations would be confined i=
n=20
>> the 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 poin=
t=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 a topic in the=
=20
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit=20
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/kGHAX6um__c=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to=20
>> 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=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9e=
7d-4851-8b28-5cd67779081a%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9=
e7d-4851-8b28-5cd67779081a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=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/1356e140-2985-4fe7-b9ee-70e40738d1cf%40isocpp.or=
g.
------=_Part_22615_576440381.1522244415132
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sorry for replying to myself, but I wanted to clarify a fe=
w things. First, I think one of the greatest strengths of C++ is the philos=
ophy of not making you pay for features you don't want/need. While ther=
e are legitimate cases for arguments along the lines of "a conforming =
implementation could..." those need to be cognizant of reality. In par=
ticular the number of conforming implementations is MUCH smaller than the n=
umber of applications using those conforming implementations. Also, the kin=
ds of restrictions I am concerned with are more a function of the applicati=
on than the platform. Some users of a platform without floating point hardw=
are (e.g. Arduino) might see software floating point as a huge advantage (i=
n terms of things like ease of development), while others using the same ch=
ip (e.g. the atmega 328p) might see software floating point as a nonstarter=
due to things like code size and runtime. It should be the goal of the sta=
ndard to encourage implementations that can gracefully scale in multiple di=
mensions (required features, code size , memory usage...) to fit the needs =
of any given application. Adding non-floating-point methods for dealing wit=
h load factor would allow conforming implementations to be written such tha=
t applications that don't want to floating point, don't have to use=
floating point.<br><br>On Wednesday, March 28, 2018 at 6:22:54 AM UTC-4, K=
evin Fitch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"a=
uto"><div>While a conforming implementation may jump through some hoops to =
minimize the impact of the floating point requirement, the biggest problem =
is the inclusion of ANY floating point. Once a floating point variable has =
been declared and manipulated, the compiler needs to include software float=
ing point routines which can be quite large, especially by the standards of=
embedded systems. Also a resource constrained embedded system is exactly t=
he place where you will likely need to manipulate max load factor to meet e=
ither memory or speed requirements.=C2=A0<br><br><div class=3D"gmail_quote"=
><div dir=3D"ltr">On Wed, Mar 28, 2018, 3:05 AM Alberto Barbati wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><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;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 i=
n the C++ standard library where floating point is required even if you did=
n't "opt-in" to floating point. E.g. see <a href=3D"http://en=
..cppreference.com/w/cpp/container/unordered_set/max_load_factor" rel=3D"nof=
ollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcontainer%2Funord=
ered_set%2Fmax_load_factor\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlelACBw=
t-yqMV-yg2KEnqzVA0yg';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcontai=
ner%2Funordered_set%2Fmax_load_factor\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGlelACBwt-yqMV-yg2KEnqzVA0yg';return true;">http://en.cppreference.c=
om/w/<wbr>cpp/container/unordered_set/<wbr>max_load_factor</a><br><br>On ma=
ny embedded systems hardware floating point is unavailable, and using softw=
are to emulate it is very expensive. Both in terms of code size and runtime=
..<br><br><span><span></span></span></div></blockquote><div><br>This is the =
kind of questions you get when cppreference is your only source. cppreferen=
ce is usually good, but having a look at the C++ standard wording may somet=
imes surprise you. Here is the description of the effect of max_load_factor=
(z)<br> in the C++ standard (emphasis mine): "<b>May</b> change the co=
ntainer=E2=80=99s maximum load factor, using z <b>as a hint</b>." This=
means that a conforming implementation on an embedded platform has at leas=
t two ways to avoid floating point computation at runtime:<br>1) it can jus=
t 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 hint to compute an approximate integral ratio =
in max_load_factor() and store the ratio, then use the integral ratio in al=
l other places. All floating point computations would be confined in the ma=
x_load_factor() call, which may even get inlined with no impact at runtime.=
Even if the call is not inlined, the costs of the floating point computati=
ons would be very limited, since the typical use-case of max_load_factor() =
is to call it just once at initialization. </div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/kGHAX6um__c/unsubscribe" rel=3D"nofollow=
" target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/kGHAX6um__c/unsubscribe';return t=
rue;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/kGHAX6um__c/unsubscribe';return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/kGHAX6um__c/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nofollow" target=3D=
"_blank" onmousedown=3D"this.href=3D'mailto:std-proposals+unsubscribe@i=
socpp.org';return true;" onclick=3D"this.href=3D'mailto:std-proposa=
ls+unsubscribe@isocpp.org';return true;">std-proposals+unsubscribe@<wbr=
>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'ma=
ilto:std-proposals@isocpp.org';return true;" onclick=3D"this.href=3D=
9;mailto:std-proposals@isocpp.org';return true;">std-proposals@isocpp.o=
rg</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" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/9d4a8ea3-9e7d-4851-8b28-5cd67779081a%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9d4a8ea3-9e7d-4851-<wbr>8b28-=
5cd67779081a%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></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/1356e140-2985-4fe7-b9ee-70e40738d1cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1356e140-2985-4fe7-b9ee-70e40738d1cf=
%40isocpp.org</a>.<br />
------=_Part_22615_576440381.1522244415132--
------=_Part_22614_1095880020.1522244415132--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Mar 2018 07:31:46 -0700 (PDT)
Raw View
------=_Part_22399_1409633125.1522247506614
Content-Type: multipart/alternative;
boundary="----=_Part_22400_1326985161.1522247506614"
------=_Part_22400_1326985161.1522247506614
Content-Type: text/plain; charset="UTF-8"
On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote:
>
> Sorry for replying to myself, but I wanted to clarify a few things. First,
> I think one of the greatest strengths of C++ is the philosophy of not
> making you pay for features you don't want/need.
>
But you have to temper that with the question: what is a "feature"?
A particular class or function from the standard library could be
considered a distinct "feature". Indeed, freestanding implementations are
not required to implement all parts of the standard library.
But I have a hard time seeing fundamental types as distinct "features".
They're called "fundamental" for a reason. I don't see a good reason why
the standards committee needs to design interfaces on the assumption that
even *seeing* the keyword `float` constitutes a major disruption to a
programmer.
That doesn't mean that they should randomly insert `float` for no good
reason. But it also doesn't mean that they need to use inconvenient types
(like a `std::ratio` or whatever) just to avoid using it in interfaces
where `float` would otherwise be quite natural.
While there are legitimate cases for arguments along the lines of "a
> conforming implementation could..." those need to be cognizant of reality.
> In particular the number of conforming implementations is MUCH smaller than
> the number of applications using those conforming implementations. Also,
> the kinds of restrictions I am concerned with are more a function of the
> application than the platform. Some users of a platform without floating
> point hardware (e.g. Arduino) might see software floating point as a huge
> advantage (in terms of things like ease of development), while others using
> the same chip (e.g. the atmega 328p) might see software floating point as a
> nonstarter due to things like code size and runtime.
>
So, the code size and runtime costs of `float` are too much for you, but
the memory and runtime costs of `unordered_set` are fine?
> It should be the goal of the standard to encourage implementations that
> can gracefully scale in multiple dimensions (required features, code size ,
> memory usage...) to fit the needs of any given application. Adding
> non-floating-point methods for dealing with load factor would allow
> conforming implementations to be written such that applications that don't
> want to floating point, don't have to use floating point.
>
--
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/7b853bcd-47f5-4c2c-841b-13e30472e14c%40isocpp.org.
------=_Part_22400_1326985161.1522247506614
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fi=
tch 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">Sor=
ry for replying to myself, but I wanted to clarify a few things. First, I t=
hink one of the greatest strengths of C++ is the philosophy of not making y=
ou pay for features you don't want/need.</div></blockquote><div><br>But=
you have to temper that with the question: what is a "feature"?<=
br><br>A particular class or function from the standard library could be co=
nsidered a distinct "feature". Indeed, freestanding implementatio=
ns are not required to implement all parts of the standard library.<br><br>=
But I have a hard time seeing fundamental types as distinct "features&=
quot;. They're called "fundamental" for a reason. I don't=
see a good reason why the standards committee needs to design interfaces o=
n the assumption that even <i>seeing</i> the keyword `float` constitutes a =
major disruption to a programmer.<br><br>That doesn't mean that they sh=
ould randomly insert `float` for no good reason. But it also doesn't me=
an that they need to use inconvenient types (like a `std::ratio` or whateve=
r) just to avoid using it in interfaces where `float` would otherwise be qu=
ite natural.<br><br></div><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"> While there are legitimate cases for arguments along the line=
s of "a conforming implementation could..." those need to be cogn=
izant of reality. In particular the number of conforming implementations is=
MUCH smaller than the number of applications using those conforming implem=
entations. Also, the kinds of restrictions I am concerned with are more a f=
unction of the application than the platform. Some users of a platform with=
out floating point hardware (e.g. Arduino) might see software floating poin=
t as a huge advantage (in terms of things like ease of development), while =
others using the same chip (e.g. the atmega 328p) might see software floati=
ng point as a nonstarter due to things like code size and runtime.</div></b=
lockquote><div><br>So, the code size and runtime costs of `float` are too m=
uch for you, but the memory and runtime costs of `unordered_set` are fine?<=
br>=C2=A0</div><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=
">It should be the goal of the standard to encourage implementations that c=
an gracefully scale in multiple dimensions (required features, code size , =
memory usage...) to fit the needs of any given application. Adding non-floa=
ting-point methods for dealing with load factor would allow conforming impl=
ementations to be written such that applications that don't want to flo=
ating point, don't have to use floating point.</div></blockquote><div><=
br>=C2=A0<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/7b853bcd-47f5-4c2c-841b-13e30472e14c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b853bcd-47f5-4c2c-841b-13e30472e14c=
%40isocpp.org</a>.<br />
------=_Part_22400_1326985161.1522247506614--
------=_Part_22399_1409633125.1522247506614--
.
Author: Kevin Fitch <kfitch42@gmail.com>
Date: Wed, 28 Mar 2018 08:16:32 -0700 (PDT)
Raw View
------=_Part_7110_650115042.1522250192777
Content-Type: multipart/alternative;
boundary="----=_Part_7111_1743433310.1522250192777"
------=_Part_7111_1743433310.1522250192777
Content-Type: text/plain; charset="UTF-8"
On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4, Nicol Bolas wrote:
>
> On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote:
>>
>> Sorry for replying to myself, but I wanted to clarify a few things.
>> First, I think one of the greatest strengths of C++ is the philosophy of
>> not making you pay for features you don't want/need.
>>
>
> But you have to temper that with the question: what is a "feature"?
>
Yes, the word feature can be a bit nebulous. But looking at the landscape
of computers chips and operating systems out there (i.e. the things the
compiler generated code interacts with), there are many things that would
count as "features": floating-point, MMU, SIMD/vector, multi-threading...
Some of these are more relevant to C++ than others. C++ has been designed
over the years to be able to work just find on both 8-bit micros running
bare metal as well as massive mutli-core servers running "real" OSs.
> A particular class or function from the standard library could be
> considered a distinct "feature". Indeed, freestanding implementations are
> not required to implement all parts of the standard library.
>
What I am concerned with is that os/cpu features that should be independent
are being bundles into a single standard library feature that means I being
pushed away from using the standard library.
But I have a hard time seeing fundamental types as distinct "features".
> They're called "fundamental" for a reason. I don't see a good reason why
> the standards committee needs to design interfaces on the assumption that
> even *seeing* the keyword `float` constitutes a major disruption to a
> programmer.
>
I do see a good reason. On many platforms, using any floating point is a
major step change that would disrupt the development process. Many projects
I have worked on had a blanket rule against using floating point. The ones
I have worked on that did not have such a rule were ones where floating
point was central to task being accomplished. I don't think you can look
at both the history and the current state of the computer chip landscape
and not notice that while EVERY CPU has integer support, but there is a
significant subset that does not have floating-point support.
> That doesn't mean that they should randomly insert `float` for no good
> reason. But it also doesn't mean that they need to use inconvenient types
> (like a `std::ratio` or whatever) just to avoid using it in interfaces
> where `float` would otherwise be quite natural.
>
I am not saying that we need to remove the 'float' functions, but I want to
be able to fully use an unordered container without calling them, so that a
decent compiler will elide them and avoid the costs that I don't want to
pay.
>
> While there are legitimate cases for arguments along the lines of "a
>> conforming implementation could..." those need to be cognizant of reality.
>> In particular the number of conforming implementations is MUCH smaller than
>> the number of applications using those conforming implementations. Also,
>> the kinds of restrictions I am concerned with are more a function of the
>> application than the platform. Some users of a platform without floating
>> point hardware (e.g. Arduino) might see software floating point as a huge
>> advantage (in terms of things like ease of development), while others using
>> the same chip (e.g. the atmega 328p) might see software floating point as a
>> nonstarter due to things like code size and runtime.
>>
>
> So, the code size and runtime costs of `float` are too much for you, but
> the memory and runtime costs of `unordered_set` are fine?
>
In a word, YES. I did not post here out of idle speculation. I ran into
exactly this case. Embedded systems are not a simple binary distinction, it
is not even something that is a simple 1 dimensional spectrum. Each system
has its own set of requirements that lead to restrictions that can
surprising.
>
>> It should be the goal of the standard to encourage implementations that
>> can gracefully scale in multiple dimensions (required features, code size ,
>> memory usage...) to fit the needs of any given application. Adding
>> non-floating-point methods for dealing with load factor would allow
>> conforming implementations to be written such that applications that don't
>> want to floating point, don't have to use floating point.
>>
>
>
>
--
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/af922ddf-a2c4-4654-a246-de2452477c95%40isocpp.org.
------=_Part_7111_1743433310.1522250192777
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4,=
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch 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">Sorry for replying =
to myself, but I wanted to clarify a few things. First, I think one of the =
greatest strengths of C++ is the philosophy of not making you pay for featu=
res you don't want/need.</div></blockquote><div><br>But you have to tem=
per that with the question: what is a "feature"?</div></div></blo=
ckquote><div><br>Yes, the word feature can be a bit nebulous.=C2=A0 But loo=
king at the landscape of computers chips and operating systems out there (i=
..e. the things the compiler generated code interacts with), there are many =
things that would count as "features": floating-point, MMU, SIMD/=
vector, multi-threading... Some of these are more relevant to C++ than othe=
rs. C++ has been designed over the years to be able to work just find on bo=
th 8-bit micros running bare metal as well as massive mutli-core servers ru=
nning "real" OSs. <br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div>A particular class or functi=
on from the standard library could be considered a distinct "feature&q=
uot;. Indeed, freestanding implementations are not required to implement al=
l parts of the standard library.<br></div></div></blockquote><div><br>What =
I am concerned with is that os/cpu features that should be independent are =
being bundles into a single standard library feature that means I being pus=
hed away from using the standard library. <br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>But I have a hard time se=
eing fundamental types as distinct "features". They're called=
"fundamental" for a reason. I don't see a good reason why th=
e standards committee needs to design interfaces on the assumption that eve=
n <i>seeing</i> the keyword `float` constitutes a major disruption to a pro=
grammer.</div></div></blockquote><div><br>I do see a good reason. On many p=
latforms, using any floating point is a major step change that would disrup=
t the development process. Many projects I have worked on had a blanket rul=
e against using floating point. The ones I have worked on that did not have=
such a rule were ones where floating point was central to task being accom=
plished.=C2=A0 I don't think you can look at both the history and the c=
urrent state of the computer chip landscape and not notice that while EVERY=
CPU has integer support, but there is a significant subset that does not h=
ave floating-point support.<br></div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>That doesn't mean that th=
ey should randomly insert `float` for no good reason. But it also doesn'=
;t mean that they need to use inconvenient types (like a `std::ratio` or wh=
atever) just to avoid using it in interfaces where `float` would otherwise =
be quite natural.<br></div></div></blockquote><div> <br>I am not saying tha=
t we need to remove the 'float' functions, but I
want to be able to fully use an unordered container without calling=20
them, so that a decent compiler will elide them and avoid the costs that
I don't want to pay.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"> While there are legitimate cases for arguments al=
ong the lines of "a conforming implementation could..." those nee=
d to be cognizant of reality. In particular the number of conforming implem=
entations is MUCH smaller than the number of applications using those confo=
rming implementations. Also, the kinds of restrictions I am concerned with =
are more a function of the application than the platform. Some users of a p=
latform without floating point hardware (e.g. Arduino) might see software f=
loating point as a huge advantage (in terms of things like ease of developm=
ent), while others using the same chip (e.g. the atmega 328p) might see sof=
tware floating point as a nonstarter due to things like code size and runti=
me.</div></blockquote><div><br>So, the code size and runtime costs of `floa=
t` are too much for you, but the memory and runtime costs of `unordered_set=
` are fine?<br></div></div></blockquote><div><br>In a word, YES. I did not =
post here out of idle speculation. I ran into exactly this case. Embedded s=
ystems are not a simple binary distinction, it is not even something that i=
s a simple 1 dimensional spectrum. Each system has its own set of requireme=
nts that lead to restrictions that can surprising.<br><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It should be the goal of =
the standard to encourage implementations that can gracefully scale in mult=
iple dimensions (required features, code size , memory usage...) to fit the=
needs of any given application. Adding non-floating-point methods for deal=
ing with load factor would allow conforming implementations to be written s=
uch that applications that don't want to floating point, don't have=
to use floating point.</div></blockquote><div><br>=C2=A0<br></div></div></=
blockquote></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/af922ddf-a2c4-4654-a246-de2452477c95%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/af922ddf-a2c4-4654-a246-de2452477c95=
%40isocpp.org</a>.<br />
------=_Part_7111_1743433310.1522250192777--
------=_Part_7110_650115042.1522250192777--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 28 Mar 2018 08:35:48 -0700 (PDT)
Raw View
------=_Part_22445_356550585.1522251348630
Content-Type: multipart/alternative;
boundary="----=_Part_22446_42649931.1522251348630"
------=_Part_22446_42649931.1522251348630
Content-Type: text/plain; charset="UTF-8"
Even if you add new interfaces to deal with the load factor, the internals
are likely to still need to use floating point math in order to continue
supporting the old interfaces. Unless you are willing to write your own
std::unordered_* containers and replace the ones shipped with libstdc++ or
libc++ with those, you will probably be stuck with some amount of floating
point math in the containers.
reserve does math on the load factor. insert does comparisons with the
load factor.
On Wednesday, March 28, 2018 at 10:16:32 AM UTC-5, Kevin Fitch wrote:
>
>
>
> On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4, Nicol Bolas wrote:
>>
>> On Wednesday, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote:
>>>
>>> Sorry for replying to myself, but I wanted to clarify a few things.
>>> First, I think one of the greatest strengths of C++ is the philosophy of
>>> not making you pay for features you don't want/need.
>>>
>>
>> But you have to temper that with the question: what is a "feature"?
>>
>
> Yes, the word feature can be a bit nebulous. But looking at the landscape
> of computers chips and operating systems out there (i.e. the things the
> compiler generated code interacts with), there are many things that would
> count as "features": floating-point, MMU, SIMD/vector, multi-threading...
> Some of these are more relevant to C++ than others. C++ has been designed
> over the years to be able to work just find on both 8-bit micros running
> bare metal as well as massive mutli-core servers running "real" OSs.
>
>
>> A particular class or function from the standard library could be
>> considered a distinct "feature". Indeed, freestanding implementations are
>> not required to implement all parts of the standard library.
>>
>
> What I am concerned with is that os/cpu features that should be
> independent are being bundles into a single standard library feature that
> means I being pushed away from using the standard library.
>
> But I have a hard time seeing fundamental types as distinct "features".
>> They're called "fundamental" for a reason. I don't see a good reason why
>> the standards committee needs to design interfaces on the assumption that
>> even *seeing* the keyword `float` constitutes a major disruption to a
>> programmer.
>>
>
> I do see a good reason. On many platforms, using any floating point is a
> major step change that would disrupt the development process. Many projects
> I have worked on had a blanket rule against using floating point. The ones
> I have worked on that did not have such a rule were ones where floating
> point was central to task being accomplished. I don't think you can look
> at both the history and the current state of the computer chip landscape
> and not notice that while EVERY CPU has integer support, but there is a
> significant subset that does not have floating-point support.
>
>
>> That doesn't mean that they should randomly insert `float` for no good
>> reason. But it also doesn't mean that they need to use inconvenient types
>> (like a `std::ratio` or whatever) just to avoid using it in interfaces
>> where `float` would otherwise be quite natural.
>>
>
> I am not saying that we need to remove the 'float' functions, but I want
> to be able to fully use an unordered container without calling them, so
> that a decent compiler will elide them and avoid the costs that I don't
> want to pay.
>
>
>>
>> While there are legitimate cases for arguments along the lines of "a
>>> conforming implementation could..." those need to be cognizant of reality.
>>> In particular the number of conforming implementations is MUCH smaller than
>>> the number of applications using those conforming implementations. Also,
>>> the kinds of restrictions I am concerned with are more a function of the
>>> application than the platform. Some users of a platform without floating
>>> point hardware (e.g. Arduino) might see software floating point as a huge
>>> advantage (in terms of things like ease of development), while others using
>>> the same chip (e.g. the atmega 328p) might see software floating point as a
>>> nonstarter due to things like code size and runtime.
>>>
>>
>> So, the code size and runtime costs of `float` are too much for you, but
>> the memory and runtime costs of `unordered_set` are fine?
>>
>
> In a word, YES. I did not post here out of idle speculation. I ran into
> exactly this case. Embedded systems are not a simple binary distinction, it
> is not even something that is a simple 1 dimensional spectrum. Each system
> has its own set of requirements that lead to restrictions that can
> surprising.
>
>
>>
>>> It should be the goal of the standard to encourage implementations that
>>> can gracefully scale in multiple dimensions (required features, code size ,
>>> memory usage...) to fit the needs of any given application. Adding
>>> non-floating-point methods for dealing with load factor would allow
>>> conforming implementations to be written such that applications that don't
>>> want to floating point, don't have to use floating point.
>>>
>>
>>
>>
>
--
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/1df72d61-2659-4864-9a6d-f8ea8fe52792%40isocpp.org.
------=_Part_22446_42649931.1522251348630
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Even if you add new interfaces to deal with the load =
factor, the internals are likely to still need to use floating point math i=
n order to continue supporting the old interfaces.=C2=A0 Unless you are wil=
ling to write your own std::unordered_* containers and replace the ones shi=
pped with libstdc++ or libc++ with those, you will probably be stuck with s=
ome amount of floating point math in the containers.</div><div><br></div><d=
iv>reserve does math on the load factor.=C2=A0 insert does comparisons with=
the load factor.<br><br>On Wednesday, March 28, 2018 at 10:16:32 AM UTC-5,=
Kevin Fitch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Wednesday, March 28, 2018 at 10:31:46 AM UTC-4, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesd=
ay, March 28, 2018 at 9:40:15 AM UTC-4, Kevin Fitch wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Sorry for replying to myself, but I=
wanted to clarify a few things. First, I think one of the greatest strengt=
hs of C++ is the philosophy of not making you pay for features you don'=
t want/need.</div></blockquote><div><br>But you have to temper that with th=
e question: what is a "feature"?</div></div></blockquote><div><br=
>Yes, the word feature can be a bit nebulous.=C2=A0 But looking at the land=
scape of computers chips and operating systems out there (i.e. the things t=
he compiler generated code interacts with), there are many things that woul=
d count as "features": floating-point, MMU, SIMD/vector, multi-th=
reading... Some of these are more relevant to C++ than others. C++ has been=
designed over the years to be able to work just find on both 8-bit micros =
running bare metal as well as massive mutli-core servers running "real=
" OSs. <br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>A particular class or function from the standard =
library could be considered a distinct "feature". Indeed, freesta=
nding implementations are not required to implement all parts of the standa=
rd library.<br></div></div></blockquote><div><br>What I am concerned with i=
s that os/cpu features that should be independent are being bundles into a =
single standard library feature that means I being pushed away from using t=
he standard library. <br><br></div><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"><div>But I have a hard time seeing fundamental types as d=
istinct "features". They're called "fundamental" fo=
r a reason. I don't see a good reason why the standards committee needs=
to design interfaces on the assumption that even <i>seeing</i> the keyword=
`float` constitutes a major disruption to a programmer.</div></div></block=
quote><div><br>I do see a good reason. On many platforms, using any floatin=
g point is a major step change that would disrupt the development process. =
Many projects I have worked on had a blanket rule against using floating po=
int. The ones I have worked on that did not have such a rule were ones wher=
e floating point was central to task being accomplished.=C2=A0 I don't =
think you can look at both the history and the current state of the compute=
r chip landscape and not notice that while EVERY CPU has integer support, b=
ut there is a significant subset that does not have floating-point support.=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>That doesn't mean that they should randomly insert `float=
` for no good reason. But it also doesn't mean that they need to use in=
convenient types (like a `std::ratio` or whatever) just to avoid using it i=
n interfaces where `float` would otherwise be quite natural.<br></div></div=
></blockquote><div> <br>I am not saying that we need to remove the 'flo=
at' functions, but I
want to be able to fully use an unordered container without calling=20
them, so that a decent compiler will elide them and avoid the costs that
I don't want to pay.<br>=C2=A0</div><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"><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"> While there are legitimate cases for arguments along t=
he lines of "a conforming implementation could..." those need to =
be cognizant of reality. In particular the number of conforming implementat=
ions is MUCH smaller than the number of applications using those conforming=
implementations. Also, the kinds of restrictions I am concerned with are m=
ore a function of the application than the platform. Some users of a platfo=
rm without floating point hardware (e.g. Arduino) might see software floati=
ng point as a huge advantage (in terms of things like ease of development),=
while others using the same chip (e.g. the atmega 328p) might see software=
floating point as a nonstarter due to things like code size and runtime.</=
div></blockquote><div><br>So, the code size and runtime costs of `float` ar=
e too much for you, but the memory and runtime costs of `unordered_set` are=
fine?<br></div></div></blockquote><div><br>In a word, YES. I did not post =
here out of idle speculation. I ran into exactly this case. Embedded system=
s are not a simple binary distinction, it is not even something that is a s=
imple 1 dimensional spectrum. Each system has its own set of requirements t=
hat lead to restrictions that can surprising.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">It should be the goal of the standa=
rd to encourage implementations that can gracefully scale in multiple dimen=
sions (required features, code size , memory usage...) to fit the needs of =
any given application. Adding non-floating-point methods for dealing with l=
oad factor would allow conforming implementations to be written such that a=
pplications that don't want to floating point, don't have to use fl=
oating point.</div></blockquote><div><br>=C2=A0<br></div></div></blockquote=
></div></blockquote></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/1df72d61-2659-4864-9a6d-f8ea8fe52792%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1df72d61-2659-4864-9a6d-f8ea8fe52792=
%40isocpp.org</a>.<br />
------=_Part_22446_42649931.1522251348630--
------=_Part_22445_356550585.1522251348630--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 28 Mar 2018 08:42:24 -0700 (PDT)
Raw View
------=_Part_23062_1254661168.1522251744654
Content-Type: multipart/alternative;
boundary="----=_Part_23063_1456266454.1522251744654"
------=_Part_23063_1456266454.1522251744654
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scritto=
:
>
> Even if you add new interfaces to deal with the load factor, the internal=
s=20
> are likely to still need to use floating point math in order to continue=
=20
> supporting the old interfaces. Unless you are willing to write your own=
=20
> std::unordered_* containers and replace the ones shipped with libstdc++ o=
r=20
> libc++ with those, you will probably be stuck with some amount of floatin=
g=20
> point math in the containers.
>
> reserve does math on the load factor. insert does comparisons with the=
=20
> load factor.
>
That is incorrect. The implementation is allowed to store and use=20
internally a fixed point representation of the max load factor and perform=
=20
math on such value. The only places in which floating point is actually=20
necessary are the interface functions max_load_factor() and load_factor().
--=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/8eb5c7cd-42ec-46bd-8aee-842ef11b885e%40isocpp.or=
g.
------=_Part_23063_1456266454.1522251744654
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2,=
Ben Craig ha scritto:<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"><div>Even if you add new interfaces to deal with the load factor, =
the internals are likely to still need to use floating point math in order =
to continue supporting the old interfaces.=C2=A0 Unless you are willing to =
write your own std::unordered_* containers and replace the ones shipped wit=
h libstdc++ or libc++ with those, you will probably be stuck with some amou=
nt of floating point math in the containers.</div><div><br></div><div>reser=
ve does math on the load factor.=C2=A0 insert does comparisons with the loa=
d factor.<br></div></div></blockquote><div><br>That is incorrect. The imple=
mentation is allowed to store and use internally a fixed point representati=
on of the max load factor and perform math on such value. The only places i=
n which floating point is actually necessary are the interface functions ma=
x_load_factor() and load_factor().<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/8eb5c7cd-42ec-46bd-8aee-842ef11b885e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8eb5c7cd-42ec-46bd-8aee-842ef11b885e=
%40isocpp.org</a>.<br />
------=_Part_23063_1456266454.1522251744654--
------=_Part_23062_1254661168.1522251744654--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Mar 2018 08:48:50 -0700 (PDT)
Raw View
------=_Part_13150_1562601011.1522252130851
Content-Type: multipart/alternative;
boundary="----=_Part_13151_342019493.1522252130851"
------=_Part_13151_342019493.1522252130851
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrote:
>
>
> Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scrit=
to:
>>
>> Even if you add new interfaces to deal with the load factor, the=20
>> internals are likely to still need to use floating point math in order t=
o=20
>> continue supporting the old interfaces. Unless you are willing to write=
=20
>> your own std::unordered_* containers and replace the ones shipped with=
=20
>> libstdc++ or libc++ with those, you will probably be stuck with some amo=
unt=20
>> of floating point math in the containers.
>>
>> reserve does math on the load factor. insert does comparisons with the=
=20
>> load factor.
>>
>
> That is incorrect. The implementation is allowed to store and use=20
> internally a fixed point representation of the max load factor and perfor=
m=20
> math on such value. The only places in which floating point is actually=
=20
> necessary are the interface functions max_load_factor() and load_factor()=
..
>
Oh yes, they're "allowed" to. But why would they? Most standard library=20
implementations are not generally written under the assumption that using=
=20
`float` is slow, so given the interface of the type, they probably just=20
store and use a `float`. Therefore, to get this benefit, you have to be=20
using an implementation that internally used fixed-point or whatever.
--=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/2ad48eb7-a635-4aaf-9216-7a390791c083%40isocpp.or=
g.
------=_Part_13151_342019493.1522252130851
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4,=
Alberto Barbati wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><br>Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Cr=
aig ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>Even if you add new interfaces to deal with the load factor, the internal=
s are likely to still need to use floating point math in order to continue =
supporting the old interfaces.=C2=A0 Unless you are willing to write your o=
wn std::unordered_* containers and replace the ones shipped with libstdc++ =
or libc++ with those, you will probably be stuck with some amount of floati=
ng point math in the containers.</div><div><br></div><div>reserve does math=
on the load factor.=C2=A0 insert does comparisons with the load factor.<br=
></div></div></blockquote><div><br>That is incorrect. The implementation is=
allowed to store and use internally a fixed point representation of the ma=
x load factor and perform math on such value. The only places in which floa=
ting point is actually necessary are the interface functions max_load_facto=
r() and load_factor().<br></div></div></blockquote><div><br>Oh yes, they=
9;re "allowed" to. But why would they? Most standard library impl=
ementations are not generally written under the assumption that using `floa=
t` is slow, so given the interface of the type, they probably just store an=
d use a `float`. Therefore, to get this benefit, you have to be using an im=
plementation that internally used fixed-point or whatever.<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/2ad48eb7-a635-4aaf-9216-7a390791c083%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ad48eb7-a635-4aaf-9216-7a390791c083=
%40isocpp.org</a>.<br />
------=_Part_13151_342019493.1522252130851--
------=_Part_13150_1562601011.1522252130851--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 28 Mar 2018 11:51:02 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">He said 'likely'.</div><div style=3D"width: 100%; font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
><br></div><div style=3D"width: 100%; font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);">The question is whether=
you can find an STL implementation that doesn't use floating point interna=
lly.</div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">Implementations _could_ use fixed point internal=
ly, but will they?<span style=3D"font-size: initial; line-height: initial; =
text-align: initial;"></span></div><div style=3D"width: 100%; font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
><br></div><div style=3D"width: 100%; font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);">Maybe they would. Or ma=
ybe they already do. You should ask your implementation. </div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);">In fact, ask them to add an extension to =
unordered_map =E2=80=8Ethat takes a percent or ratio or something. On=
ce there is an implementation with the extension, it might be easier to con=
vince the committee. </div><div style=3D"width: 100%; font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><b=
r></div><div style=3D"width: 100%; font-size: initial; font-family: Calibri=
, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align:=
initial; background-color: rgb(255, 255, 255);">Either way, I think you co=
uld write a proposal and see what the committee thinks.</div> =
=
<div style=3D"width: 100%; font=
-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; =
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 25=
5, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calibri, 'Sl=
ate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);">Sent from my Bla=
ckBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-spacing:0=
px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align:=
initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb(181, 19=
6, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, =
'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Alberto=
Barbati</div><div><b>Sent: </b>Wednesday, March 28, 2018 11:42 AM</div><di=
v><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b=
>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] Re:=
Remove floating point requirement for unordered (multi) set/map</div></div=
></td></tr></tbody></table><div style=3D"border-style: solid none none; bor=
der-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initia=
l; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><d=
iv id=3D"_originalContent" style=3D""><div dir=3D"ltr"><br>Il giorno mercol=
ed=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scritto:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Even if you add new int=
erfaces to deal with the load factor, the internals are likely to still nee=
d to use floating point math in order to continue supporting the old interf=
aces. Unless you are willing to write your own std::unordered_* conta=
iners and replace the ones shipped with libstdc++ or libc++ with those, you=
will probably be stuck with some amount of floating point math in the cont=
ainers.</div><div><br></div><div>reserve does math on the load factor. =
; insert does comparisons with the load factor.<br></div></div></blockquote=
><div><br>That is incorrect. The implementation is allowed to store and use=
internally a fixed point representation of the max load factor and perform=
math on such value. The only places in which floating point is actually ne=
cessary are the interface functions max_load_factor() and load_factor().<br=
></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/8eb5c7cd-42ec-46bd-8aee-842ef11b885e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/8eb5c7cd-42ec-46bd-8aee-842ef11b=
885e%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20180328155102.5083219.89905.48476%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20180328155102.5083219.89905.48476%40gm=
ail.com</a>.<br />
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 28 Mar 2018 08:53:01 -0700 (PDT)
Raw View
------=_Part_23046_1912591152.1522252381663
Content-Type: multipart/alternative;
boundary="----=_Part_23047_1007668085.1522252381663"
------=_Part_23047_1007668085.1522252381663
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nicol Bolas ha scrit=
to:
>
>
> On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrote:
>>
>>
>> Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scri=
tto:
>>>
>>> Even if you add new interfaces to deal with the load factor, the=20
>>> internals are likely to still need to use floating point math in order =
to=20
>>> continue supporting the old interfaces. Unless you are willing to writ=
e=20
>>> your own std::unordered_* containers and replace the ones shipped with=
=20
>>> libstdc++ or libc++ with those, you will probably be stuck with some am=
ount=20
>>> of floating point math in the containers.
>>>
>>> reserve does math on the load factor. insert does comparisons with the=
=20
>>> load factor.
>>>
>>
>> That is incorrect. The implementation is allowed to store and use=20
>> internally a fixed point representation of the max load factor and perfo=
rm=20
>> math on such value. The only places in which floating point is actually=
=20
>> necessary are the interface functions max_load_factor() and load_factor(=
).
>>
>
> Oh yes, they're "allowed" to. But why would they? Most standard library=
=20
> implementations are not generally written under the assumption that using=
=20
> `float` is slow, so given the interface of the type, they probably just=
=20
> store and use a `float`. Therefore, to get this benefit, you have to be=
=20
> using an implementation that internally used fixed-point or whatever.
>
QOI. My point is that an implementation specifically targeted to embedded=
=20
platform *can* do that. Of course, general purpose libraries like libstdc++=
=20
and libc++ probably won't do that.
--=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/8698cc1b-bce1-4c23-bf81-2cab986afe5a%40isocpp.or=
g.
------=_Part_23047_1007668085.1522252381663
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nic=
ol Bolas ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Bar=
bati 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"><br>Il =
giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scritto:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Even if you add=
new interfaces to deal with the load factor, the internals are likely to s=
till need to use floating point math in order to continue supporting the ol=
d interfaces.=C2=A0 Unless you are willing to write your own std::unordered=
_* containers and replace the ones shipped with libstdc++ or libc++ with th=
ose, you will probably be stuck with some amount of floating point math in =
the containers.</div><div><br></div><div>reserve does math on the load fact=
or.=C2=A0 insert does comparisons with the load factor.<br></div></div></bl=
ockquote><div><br>That is incorrect. The implementation is allowed to store=
and use internally a fixed point representation of the max load factor and=
perform math on such value. The only places in which floating point is act=
ually necessary are the interface functions max_load_factor() and load_fact=
or().<br></div></div></blockquote><div><br>Oh yes, they're "allowe=
d" to. But why would they? Most standard library implementations are n=
ot generally written under the assumption that using `float` is slow, so gi=
ven the interface of the type, they probably just store and use a `float`. =
Therefore, to get this benefit, you have to be using an implementation that=
internally used fixed-point or whatever.<br></div></div></blockquote><div>=
<br>QOI. My point is that an implementation specifically targeted to embedd=
ed platform *can* do that. Of course, general purpose libraries like libstd=
c++ and libc++ probably won't do that.<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/8698cc1b-bce1-4c23-bf81-2cab986afe5a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8698cc1b-bce1-4c23-bf81-2cab986afe5a=
%40isocpp.org</a>.<br />
------=_Part_23047_1007668085.1522252381663--
------=_Part_23046_1912591152.1522252381663--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Wed, 28 Mar 2018 14:31:48 -0700 (PDT)
Raw View
------=_Part_593_1954642471.1522272708442
Content-Type: multipart/alternative;
boundary="----=_Part_594_722857617.1522272708442"
------=_Part_594_722857617.1522272708442
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Implementations that are targeted at embedded platforms that are fine with=
=20
allocations, fine with exceptions or termination semantics, but not fine=20
with floating point.
Note however that libc++ and libstdc++ are both open source. If you are=20
willing to maintain your own toolchain, you can fork them. If you modify=
=20
the internals to not use floating point, and you never call the load factor=
=20
methods, you won't get the floating point size hit.
On Wednesday, March 28, 2018 at 10:53:01 AM UTC-5, Alberto Barbati wrote:
>
> Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nicol Bolas ha scr=
itto:
>>
>>
>> On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrote=
:
>>>
>>>
>>> Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scr=
itto:
>>>>
>>>> Even if you add new interfaces to deal with the load factor, the=20
>>>> internals are likely to still need to use floating point math in order=
to=20
>>>> continue supporting the old interfaces. Unless you are willing to wri=
te=20
>>>> your own std::unordered_* containers and replace the ones shipped with=
=20
>>>> libstdc++ or libc++ with those, you will probably be stuck with some a=
mount=20
>>>> of floating point math in the containers.
>>>>
>>>> reserve does math on the load factor. insert does comparisons with th=
e=20
>>>> load factor.
>>>>
>>>
>>> That is incorrect. The implementation is allowed to store and use=20
>>> internally a fixed point representation of the max load factor and perf=
orm=20
>>> math on such value. The only places in which floating point is actually=
=20
>>> necessary are the interface functions max_load_factor() and load_factor=
().
>>>
>>
>> Oh yes, they're "allowed" to. But why would they? Most standard library=
=20
>> implementations are not generally written under the assumption that usin=
g=20
>> `float` is slow, so given the interface of the type, they probably just=
=20
>> store and use a `float`. Therefore, to get this benefit, you have to be=
=20
>> using an implementation that internally used fixed-point or whatever.
>>
>
> QOI. My point is that an implementation specifically targeted to embedded=
=20
> platform *can* do that. Of course, general purpose libraries like libstdc=
++=20
> and libc++ probably won't do that.
>
--=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/7b2a1e15-f345-4749-ab74-b5a53b5dbed0%40isocpp.or=
g.
------=_Part_594_722857617.1522272708442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Implementations that are targeted at embedded platforms th=
at are fine with allocations, fine with exceptions or termination semantics=
, but not fine with floating point.<div><br></div><div>Note however that li=
bc++ and libstdc++ are both open source.=C2=A0 If you are willing to mainta=
in your own toolchain, you can fork them.=C2=A0 If you modify the internals=
to not use floating point, and you never call the load factor methods, you=
won't get the floating point size hit.<br><br>On Wednesday, March 28, =
2018 at 10:53:01 AM UTC-5, Alberto Barbati wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">Il giorno mercoled=C3=AC 28 marzo 2018 =
17:48:50 UTC+2, Nicol Bolas ha scritto:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br>On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4,=
Alberto Barbati 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"><br>Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig h=
a scritto:<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"><div>Eve=
n if you add new interfaces to deal with the load factor, the internals are=
likely to still need to use floating point math in order to continue suppo=
rting the old interfaces.=C2=A0 Unless you are willing to write your own st=
d::unordered_* containers and replace the ones shipped with libstdc++ or li=
bc++ with those, you will probably be stuck with some amount of floating po=
int math in the containers.</div><div><br></div><div>reserve does math on t=
he load factor.=C2=A0 insert does comparisons with the load factor.<br></di=
v></div></blockquote><div><br>That is incorrect. The implementation is allo=
wed to store and use internally a fixed point representation of the max loa=
d factor and perform math on such value. The only places in which floating =
point is actually necessary are the interface functions max_load_factor() a=
nd load_factor().<br></div></div></blockquote><div><br>Oh yes, they're =
"allowed" to. But why would they? Most standard library implement=
ations are not generally written under the assumption that using `float` is=
slow, so given the interface of the type, they probably just store and use=
a `float`. Therefore, to get this benefit, you have to be using an impleme=
ntation that internally used fixed-point or whatever.<br></div></div></bloc=
kquote><div><br>QOI. My point is that an implementation specifically target=
ed to embedded platform *can* do that. Of course, general purpose libraries=
like libstdc++ and libc++ probably won't do that.<br></div></div></blo=
ckquote></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/7b2a1e15-f345-4749-ab74-b5a53b5dbed0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b2a1e15-f345-4749-ab74-b5a53b5dbed0=
%40isocpp.org</a>.<br />
------=_Part_594_722857617.1522272708442--
------=_Part_593_1954642471.1522272708442--
.
Author: Kevin Fitch <kfitch42@gmail.com>
Date: Thu, 29 Mar 2018 06:59:52 -0700 (PDT)
Raw View
------=_Part_2735_1257862455.1522331992928
Content-Type: multipart/alternative;
boundary="----=_Part_2736_956759062.1522331992929"
------=_Part_2736_956759062.1522331992929
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote:
>
> Implementations that are targeted at embedded platforms that are fine wit=
h=20
> allocations, fine with exceptions or termination semantics, but not fine=
=20
> with floating point.
>
To clarify, was that statement meant to be a question? Perhaps you meant to=
=20
say: Do there exist ... And, I would say, emphatically, there are=20
applications using implementations of the STL targeted at embedded=20
platforms where that is true. Most often I see applications that are fine=
=20
with allocations (with a few restrictions), but not fine with exceptions or=
=20
floating point. They key is that implementations targeted at embedded=20
platforms need to deal with applications that are (or are not) fine with=20
each of those (and many other things) independently. You can (with a little=
=20
effort) use all the features of the STL without using exceptions (e.g.=20
using operator[] instead of "at" to access members of a vector). You can=20
use allocators to deal with restrictions on allocation on the platform...=
=20
>
> Note however that libc++ and libstdc++ are both open source. If you are=
=20
> willing to maintain your own toolchain, you can fork them. If you modify=
=20
> the internals to not use floating point, and you never call the load fact=
or=20
> methods, you won't get the floating point size hit.
>
Sure, and something like that is probably going to have to be my short term=
=20
solution. I was just hoping to get to a place where I (and other=20
developers) might not have to do that in the future. My point was that the=
=20
current standard makes it impossible to create an implementation that can=
=20
be used fully while avoiding floating point. I see this at the same level=
=20
as having both operator[] and "at" so that the the user/application can=20
decide what features they want to pay for.=20
>
> On Wednesday, March 28, 2018 at 10:53:01 AM UTC-5, Alberto Barbati wrote:
>>
>> Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nicol Bolas ha sc=
ritto:
>>>
>>>
>>> On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrot=
e:
>>>>
>>>>
>>>> Il giorno mercoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha sc=
ritto:
>>>>>
>>>>> Even if you add new interfaces to deal with the load factor, the=20
>>>>> internals are likely to still need to use floating point math in orde=
r to=20
>>>>> continue supporting the old interfaces. Unless you are willing to wr=
ite=20
>>>>> your own std::unordered_* containers and replace the ones shipped wit=
h=20
>>>>> libstdc++ or libc++ with those, you will probably be stuck with some =
amount=20
>>>>> of floating point math in the containers.
>>>>>
>>>>> reserve does math on the load factor. insert does comparisons with=
=20
>>>>> the load factor.
>>>>>
>>>>
>>>> That is incorrect. The implementation is allowed to store and use=20
>>>> internally a fixed point representation of the max load factor and per=
form=20
>>>> math on such value. The only places in which floating point is actuall=
y=20
>>>> necessary are the interface functions max_load_factor() and load_facto=
r().
>>>>
>>>
>>> Oh yes, they're "allowed" to. But why would they? Most standard library=
=20
>>> implementations are not generally written under the assumption that usi=
ng=20
>>> `float` is slow, so given the interface of the type, they probably just=
=20
>>> store and use a `float`. Therefore, to get this benefit, you have to be=
=20
>>> using an implementation that internally used fixed-point or whatever.
>>>
>>
>> QOI. My point is that an implementation specifically targeted to embedde=
d=20
>> platform *can* do that. Of course, general purpose libraries like libstd=
c++=20
>> and libc++ probably won't do that.
>>
>
--=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/fa334b81-aa3e-4542-92cf-42a890677689%40isocpp.or=
g.
------=_Part_2736_956759062.1522331992929
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, =
Ben Craig 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"lt=
r">Implementations that are targeted at embedded platforms that are fine wi=
th allocations, fine with exceptions or termination semantics, but not fine=
with floating point.</div></blockquote><div>To clarify, was that statement=
meant to be a question? Perhaps you meant to say: Do there exist ... And, =
I would say, emphatically, there are applications using implementations of =
the STL targeted at embedded platforms where that is true. Most often I see=
applications that are fine with allocations (with a few restrictions), but=
not fine with exceptions or floating point. They key is that implementatio=
ns targeted at embedded platforms need to deal with applications that are (=
or are not) fine with each of those (and many other things) independently. =
You can (with a little effort) use all the features of the STL without usin=
g exceptions (e.g. using operator[] instead of "at" to access mem=
bers of a vector). You can use allocators to deal with restrictions on allo=
cation on the platform... <br></div><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"><div><br></div><div>Note however that libc++ and lib=
stdc++ are both open source.=C2=A0 If you are willing to maintain your own =
toolchain, you can fork them.=C2=A0 If you modify the internals to not use =
floating point, and you never call the load factor methods, you won't g=
et the floating point size hit.<br></div></div></blockquote><div>Sure, and =
something like that is probably going to have to be my short term solution.=
I was just hoping to get to a place where I (and other developers) might n=
ot have to do that in the future. My point was that the current standard ma=
kes it impossible to create an implementation that can be used fully while =
avoiding floating point. I see this at the same level as having both operat=
or[] and "at" so that the the user/application can decide what fe=
atures they want to pay for. <br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><br>On Wednesday, March 28, 2018 at 10:53:01=
AM UTC-5, Alberto Barbati wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">Il giorno mercoled=C3=AC 28 marzo 2018 17:48:50 UTC+2, Nicol=
Bolas ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br>On Wednesday, March 28, 2018 at 11:42:24 AM UTC-4, Alberto Barbati wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Il giorno me=
rcoled=C3=AC 28 marzo 2018 17:35:48 UTC+2, Ben Craig ha scritto:<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"><div>Even if you add new inte=
rfaces to deal with the load factor, the internals are likely to still need=
to use floating point math in order to continue supporting the old interfa=
ces.=C2=A0 Unless you are willing to write your own std::unordered_* contai=
ners and replace the ones shipped with libstdc++ or libc++ with those, you =
will probably be stuck with some amount of floating point math in the conta=
iners.</div><div><br></div><div>reserve does math on the load factor.=C2=A0=
insert does comparisons with the load factor.<br></div></div></blockquote>=
<div><br>That is incorrect. The implementation is allowed to store and use =
internally a fixed point representation of the max load factor and perform =
math on such value. The only places in which floating point is actually nec=
essary are the interface functions max_load_factor() and load_factor().<br>=
</div></div></blockquote><div><br>Oh yes, they're "allowed" t=
o. But why would they? Most standard library implementations are not genera=
lly written under the assumption that using `float` is slow, so given the i=
nterface of the type, they probably just store and use a `float`. Therefore=
, to get this benefit, you have to be using an implementation that internal=
ly used fixed-point or whatever.<br></div></div></blockquote><div><br>QOI. =
My point is that an implementation specifically targeted to embedded platfo=
rm *can* do that. Of course, general purpose libraries like libstdc++ and l=
ibc++ probably won't do that.<br></div></div></blockquote></div></div><=
/blockquote></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/fa334b81-aa3e-4542-92cf-42a890677689%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fa334b81-aa3e-4542-92cf-42a890677689=
%40isocpp.org</a>.<br />
------=_Part_2736_956759062.1522331992929--
------=_Part_2735_1257862455.1522331992928--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Mar 2018 17:11:58 +0300
Raw View
On 29 March 2018 at 16:59, Kevin Fitch <kfitch42@gmail.com> wrote:
>
>
> On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote:
>>
>> Implementations that are targeted at embedded platforms that are fine with
>> allocations, fine with exceptions or termination semantics, but not fine
>> with floating point.
>
> To clarify, was that statement meant to be a question? Perhaps you meant to
> say: Do there exist ... And, I would say, emphatically, there are
> applications using implementations of the STL targeted at embedded platforms
> where that is true. Most often I see applications that are fine with
> allocations (with a few restrictions), but not fine with exceptions or
> floating point. They key is that implementations targeted at embedded
> platforms need to deal with applications that are (or are not) fine with
> each of those (and many other things) independently. You can (with a little
> effort) use all the features of the STL without using exceptions (e.g. using
> operator[] instead of "at" to access members of a vector). You can use
> allocators to deal with restrictions on allocation on the platform...
>>
>>
>> Note however that libc++ and libstdc++ are both open source. If you are
>> willing to maintain your own toolchain, you can fork them. If you modify
>> the internals to not use floating point, and you never call the load factor
>> methods, you won't get the floating point size hit.
>
> Sure, and something like that is probably going to have to be my short term
> solution. I was just hoping to get to a place where I (and other developers)
> might not have to do that in the future. My point was that the current
> standard makes it impossible to create an implementation that can be used
> fully while avoiding floating point. I see this at the same level as having
> both operator[] and "at" so that the the user/application can decide what
> features they want to pay for.
Makes perfect sense to me.
--
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/CAFk2RUZP6qS5nA-0Pc2TcDrm%2BfFM-JRiWevyre1srHdCnW08eg%40mail.gmail.com.
.
Author: John McFarlane <john@mcfarlane.name>
Date: Fri, 30 Mar 2018 02:35:55 +0000
Raw View
--001a1142ee0a1a477e0568981a2e
Content-Type: text/plain; charset="UTF-8"
On Thu, Mar 29, 2018 at 6:59 AM Kevin Fitch <kfitch42@gmail.com> wrote:
>
>
> On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote:
>>
>> Implementations that are targeted at embedded platforms that are fine
>> with allocations, fine with exceptions or termination semantics, but not
>> fine with floating point.
>>
> To clarify, was that statement meant to be a question? Perhaps you meant
> to say: Do there exist ... And, I would say, emphatically, there are
> applications using implementations of the STL targeted at embedded
> platforms where that is true. Most often I see applications that are fine
> with allocations (with a few restrictions), but not fine with exceptions or
> floating point. They key is that implementations targeted at embedded
> platforms need to deal with applications that are (or are not) fine with
> each of those (and many other things) independently. You can (with a little
> effort) use all the features of the STL without using exceptions (e.g.
> using operator[] instead of "at" to access members of a vector). You can
> use allocators to deal with restrictions on allocation on the platform...
>
FWIW, one of the developers who recently inquired about my fixed-point type
is working on a retro game project targetted at the 386. I don't think
dynamic allocations were ever considered extravagent on PC but floats
certainly used to be. That's because floating-point is a lot more costly
and complex in everything but use.
--
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/CABPJVnRPWefvTwug--CdZ0zW6B7Km3-MW0UzgiVLJcbeqdsbKg%40mail.gmail.com.
--001a1142ee0a1a477e0568981a2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Mar 29=
, 2018 at 6:59 AM Kevin Fitch <<a href=3D"mailto:kfitch42@gmail.com">kfi=
tch42@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><br><br>On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben =
Craig 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">Implem=
entations that are targeted at embedded platforms that are fine with alloca=
tions, fine with exceptions or termination semantics, but not fine with flo=
ating point.</div></blockquote></div><div dir=3D"ltr"><div>To clarify, was =
that statement meant to be a question? Perhaps you meant to say: Do there e=
xist ... And, I would say, emphatically, there are applications using imple=
mentations of the STL targeted at embedded platforms where that is true. Mo=
st often I see applications that are fine with allocations (with a few rest=
rictions), but not fine with exceptions or floating point. They key is that=
implementations targeted at embedded platforms need to deal with applicati=
ons that are (or are not) fine with each of those (and many other things) i=
ndependently. You can (with a little effort) use all the features of the ST=
L without using exceptions (e.g. using operator[] instead of "at"=
to access members of a vector). You can use allocators to deal with restri=
ctions on allocation on the platform... <br></div></div></blockquote><div><=
br>FWIW, one of the developers who recently inquired about my fixed-point=
=20
type is working on a retro game project targetted at the 386. I don't=
=20
think dynamic allocations were ever considered extravagent on PC but=20
floats certainly used to be. That's because floating-point is a lot mor=
e=20
costly and complex in everything but use.</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/CABPJVnRPWefvTwug--CdZ0zW6B7Km3-MW0Uz=
giVLJcbeqdsbKg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRPWefvTwug=
--CdZ0zW6B7Km3-MW0UzgiVLJcbeqdsbKg%40mail.gmail.com</a>.<br />
--001a1142ee0a1a477e0568981a2e--
.
Author: Ben Craig <ben.craig@gmail.com>
Date: Fri, 30 Mar 2018 12:27:20 -0700 (PDT)
Raw View
------=_Part_6875_1074325237.1522438040466
Content-Type: multipart/alternative;
boundary="----=_Part_6876_214522182.1522438040466"
------=_Part_6876_214522182.1522438040466
Content-Type: text/plain; charset="UTF-8"
On Thursday, March 29, 2018 at 8:59:53 AM UTC-5, Kevin Fitch wrote:
>
>
>
> On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig wrote:
>>
>> Implementations that are targeted at embedded platforms that are fine
>> with allocations, fine with exceptions or termination semantics, but not
>> fine with floating point.
>>
> To clarify, was that statement meant to be a question? Perhaps you meant
> to say: Do there exist ... And, I would say, emphatically, there are
> applications using implementations of the STL targeted at embedded
> platforms where that is true. Most often I see applications that are fine
> with allocations (with a few restrictions), but not fine with exceptions or
> floating point. They key is that implementations targeted at embedded
> platforms need to deal with applications that are (or are not) fine with
> each of those (and many other things) independently. You can (with a little
> effort) use all the features of the STL without using exceptions (e.g.
> using operator[] instead of "at" to access members of a vector). You can
> use allocators to deal with restrictions on allocation on the platform...
>
The point of that statement was more to point out that this is a very niche
use case. Embedded and exceptionless overlap quite a bit. Embedded with a
heap is a smaller audience. Embedded with a heap that doesn't use floating
point is even smaller. I typically see the heap getting tossed out before
floating point, not because of size, but because of the desire to avoid
fragmentation when running for long periods of time.
I agree that floating point use in unordered_map is a problem. If I had
been doing standards work back when the unordered containers were being
proposed, I would be against floating point in those places. I feel that,
for the most part, the damage is done though. Adding more interfaces
doesn't fix the need for implemenations to use floating point under the
hood. If the floating point usage were just at the load_factor calls, then
extra interfaces could fix things (like with at() and op[]). However, uses
of the floating point values typically extends to any of the growing
operations. Implementations could provide a configuration switch to avoid
floating point, but I doubt they could make that the default. Each new
configuration switch is extra testing burden that needs to be justified
with enough users. If I were the maintainer of those libraries, I would
need a lot of convincing that this is a common and serious enough problem
to justify adding a configuration switch for it.
--
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/5001768e-3ea3-4c97-9867-43c5eb56e4ed%40isocpp.org.
------=_Part_6876_214522182.1522438040466
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Thursday, March 29, 2018 at 8:59:53 AM UTC-5, Kevin=
Fitch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><br>On Wednesday, March 28, 2018 at 5:31:48 PM UTC-4, Ben Craig 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">Implementations tha=
t are targeted at embedded platforms that are fine with allocations, fine w=
ith exceptions or termination semantics, but not fine with floating point.<=
/div></blockquote><div>To clarify, was that statement meant to be a questio=
n? Perhaps you meant to say: Do there exist ... And, I would say, emphatica=
lly, there are applications using implementations of the STL targeted at em=
bedded platforms where that is true. Most often I see applications that are=
fine with allocations (with a few restrictions), but not fine with excepti=
ons or floating point. They key is that implementations targeted at embedde=
d platforms need to deal with applications that are (or are not) fine with =
each of those (and many other things) independently. You can (with a little=
effort) use all the features of the STL without using exceptions (e.g. usi=
ng operator[] instead of "at" to access members of a vector). You=
can use allocators to deal with restrictions on allocation on the platform=
.... <br></div></div></blockquote><div><br></div><div>The point of that stat=
ement was more to point out that this is a very niche use case.=C2=A0 Embed=
ded and exceptionless overlap quite a bit.=C2=A0 Embedded with a heap is a =
smaller audience.=C2=A0 Embedded with a heap that doesn't use floating =
point is even smaller.=C2=A0 I typically see the heap getting tossed out be=
fore floating point, not because of size, but because of the desire to avoi=
d fragmentation when running for long periods of time.</div><div><br></div>=
<div>I agree that floating point use in unordered_map is a problem.=C2=A0 I=
f I had been doing standards work back when the unordered containers were b=
eing proposed, I would be against floating point in those places.=C2=A0 I f=
eel that, for the most part, the damage is done though.=C2=A0 Adding more i=
nterfaces doesn't fix the need for implemenations to use floating point=
under the hood.=C2=A0 If the floating point usage were just at the load_fa=
ctor calls, then extra interfaces could fix things (like with at() and op[]=
).=C2=A0 However, uses of the floating point values typically extends to an=
y of the growing operations.=C2=A0 Implementations could provide a configur=
ation switch to avoid floating point, but I doubt they could make that the =
default.=C2=A0 Each new configuration switch is extra testing burden that n=
eeds to be justified with enough users.=C2=A0 If I were the maintainer of t=
hose libraries, I would need a lot of convincing that this is a common and =
serious enough problem to justify adding a configuration switch for it.</di=
v></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/5001768e-3ea3-4c97-9867-43c5eb56e4ed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5001768e-3ea3-4c97-9867-43c5eb56e4ed=
%40isocpp.org</a>.<br />
------=_Part_6876_214522182.1522438040466--
------=_Part_6875_1074325237.1522438040466--
.