------=_Part_2670_1860533616.1539803762753
Content-Type: multipart/alternative;
 boundary="----=_Part_2671_1939915150.1539803762753"

------=_Part_2671_1939915150.1539803762753
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In P0709, Herb Sutter proposes a zero-overhead deterministic variation of=
=20
the exception mechanism by throwing a value of a size equivalent to two=20
pointers.

I generally like the proposal a lot. I am doing HPC programming and=20
micro-controller programming and do see a lot of benefit in squelching=20
objections to the use of exceptions.
However, when it comes to the treatment of heap exhaustion and, more=20
importantly, the impact of it on the standard library, I am finding the=20
proposal to be disturbing.
In section 4.3.3 Herb proposes:

>
>    -  For each standard function for which allocation is the only=20
>    reportable error, make the function noexcept. (We expect this to resul=
t in=20
>    making a large majority of functions in the standard library noexcept,=
=20
>    including default and user-replaced ::operator new.)=20
>
>
>    - For code that wants to handle heap allocation failures, provide=20
>    explicit =E2=80=9Ctry to allocate=E2=80=9D functions including the exi=
sting new(nothrow)
>
> However this approach is disturbing. It is essentially saying to go back=
=20
to an equivalent of testing an error code on return of every single call.=
=20
Also because it goes against the ideas of writing a single generic routine=
=20
for an algorithm because it seems to imply that every time I want to write=
=20
an algorithm that involves a standard library function that does a memory=
=20
allocation, I should write both a regular version and a try_***  version.=
=20
So Herb wants that the vector<T> push_back should be noexcept while the=20
try_push_back can throw.
Though, I can see the use for having a try_*** in places, I wonder why he=
=20
does not suggest to let the allocator used make the decision? Something=20
like:
> void push_back (const value_type& val) throws( can_throw_v<Alloc> ) ;

In my HPC work, I write library in which users can supply a memory buffer=
=20
that my code can use. If I run out of memory, it is out of the question=20
that the code would crash. Instead it should be reported to the user that=
=20
she needs to provide a bigger buffer.  I can do that by using an allocator=
=20
that throws an exception. Using a solution like I suggest above would allow=
=20
to still have noexcept if the user is fine with terminate being called and=
=20
still allow to handle cases like mine gracefully in a way that I can report=
=20
to the caller as they are expecting. If the standard library always calls=
=20
terminate on failure of allocation, then I'll have to resort to not using=
=20
the standard library, but using a  modified clone of it. This would be=20
ironic,  as one of the motivations of his proposal in the first place is=20
that people are not using the standard library.

--=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/cc411e93-53a3-4b24-8e02-68fda610c15e%40isocpp.or=
g.

------=_Part_2671_1939915150.1539803762753
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In P0709, Herb Sutter proposes a zero-overhead determinist=
ic variation of the exception mechanism by throwing a value of a size equiv=
alent to two pointers.<div><br></div><div>I generally like the proposal a l=
ot. I am doing HPC programming and micro-controller programming and do see =
a lot of benefit in squelching objections to the use of exceptions.</div><d=
iv>However, when it comes to the treatment of heap exhaustion and, more imp=
ortantly, the impact of it on the standard library, I am finding the propos=
al to be disturbing.</div><div>In section 4.3.3 Herb proposes:</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
 1px solid rgb(204, 204, 204); padding-left: 1ex;"><ul><li>=C2=A0For each s=
tandard function for which allocation is the only reportable error, make th=
e function noexcept.
(We expect this to result in making a large majority of functions in the st=
andard library noexcept,
including default and user-replaced ::operator new.)=C2=A0</li></ul></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><ul><li> Fo=
r code that wants to handle heap allocation failures, provide explicit =E2=
=80=9Ctry to allocate=E2=80=9D functions including
the existing new(nothrow)</li></ul></blockquote><div>However this approach =
is disturbing. It is essentially saying to go back to an equivalent of test=
ing an error code on return of every single call. Also because it goes agai=
nst the ideas of writing a single generic routine for an algorithm because =
it seems to imply that every time I want to write an algorithm that involve=
s a standard library function that does a memory allocation, I should write=
 both a regular version and a try_***=C2=A0 version.=C2=A0</div><div>So Her=
b wants that the vector&lt;T&gt; push_back should be noexcept while the try=
_push_back can throw.</div><div>Though, I can see the use for having a try_=
*** in places, I wonder why he does not suggest to let the allocator used m=
ake the decision? Something like:</div><div>&gt;=C2=A0<span style=3D"backgr=
ound-color: rgb(250, 255, 250); color: rgb(0, 128, 0); font-size: 12px;">vo=
id push_back (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; )=
 ;</span></div><div><span style=3D"background-color: rgb(250, 255, 250); co=
lor: rgb(0, 128, 0); font-size: 12px;"><br></span></div><div><font color=3D=
"#000000"><span style=3D"font-size: 12px; background-color: rgb(250, 255, 2=
50);">In my HPC work, I write library in which users can supply a memory bu=
ffer that my code can use. If I run out of memory, it is out of the questio=
n that the code would crash. Instead it should be reported to the user that=
 she needs to provide a bigger buffer.=C2=A0 I can do that by using an allo=
cator that throws an exception. Using a solution like I suggest above would=
 allow to still have noexcept if the user is fine with terminate being call=
ed and still allow to handle cases like mine gracefully in a way that I can=
 report to the caller as they are expecting. If the standard library always=
 calls terminate on failure of allocation, then I&#39;ll have to resort to =
not using the standard library, but using a=C2=A0 modified clone of it. Thi=
s would be ironic,=C2=A0 as one of the motivations of his proposal in the f=
irst place is that people are not using the standard library.</span></font>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/cc411e93-53a3-4b24-8e02-68fda610c15e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e=
%40isocpp.org</a>.<br />

------=_Part_2671_1939915150.1539803762753--

------=_Part_2670_1860533616.1539803762753--

.

--0000000000009e4df705788c5195
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It sounds like what you are suggesting is that instead of making library
functions that can throw unconditionally noexcept, we:

* Make them conditionally noexcept if any user defined allocators used can
throw, and
* Make std::allocator and operator new (aka the defaults) noexcept.

The result is the same in the default case; out of memory is fatal. But if
you use a customize allocator that can throw, you get the current semantics=
..

This sounds reasonable to me.

Have you spoke to Herb?


On Wed, Oct 17, 2018, 3:16 PM <michel.lesoinne@gmail.com> wrote:

> In P0709, Herb Sutter proposes a zero-overhead deterministic variation of
> the exception mechanism by throwing a value of a size equivalent to two
> pointers.
>
> I generally like the proposal a lot. I am doing HPC programming and
> micro-controller programming and do see a lot of benefit in squelching
> objections to the use of exceptions.
> However, when it comes to the treatment of heap exhaustion and, more
> importantly, the impact of it on the standard library, I am finding the
> proposal to be disturbing.
> In section 4.3.3 Herb proposes:
>
>>
>>    -  For each standard function for which allocation is the only
>>    reportable error, make the function noexcept. (We expect this to resu=
lt in
>>    making a large majority of functions in the standard library noexcept=
,
>>    including default and user-replaced ::operator new.)
>>
>>
>>    - For code that wants to handle heap allocation failures, provide
>>    explicit =E2=80=9Ctry to allocate=E2=80=9D functions including the ex=
isting new(nothrow)
>>
>> However this approach is disturbing. It is essentially saying to go back
> to an equivalent of testing an error code on return of every single call.
> Also because it goes against the ideas of writing a single generic routin=
e
> for an algorithm because it seems to imply that every time I want to writ=
e
> an algorithm that involves a standard library function that does a memory
> allocation, I should write both a regular version and a try_***  version.
> So Herb wants that the vector<T> push_back should be noexcept while the
> try_push_back can throw.
> Though, I can see the use for having a try_*** in places, I wonder why he
> does not suggest to let the allocator used make the decision? Something
> like:
> > void push_back (const value_type& val) throws( can_throw_v<Alloc> ) ;
>
> In my HPC work, I write library in which users can supply a memory buffer
> that my code can use. If I run out of memory, it is out of the question
> that the code would crash. Instead it should be reported to the user that
> she needs to provide a bigger buffer.  I can do that by using an allocato=
r
> that throws an exception. Using a solution like I suggest above would all=
ow
> to still have noexcept if the user is fine with terminate being called an=
d
> still allow to handle cases like mine gracefully in a way that I can repo=
rt
> to the caller as they are expecting. If the standard library always calls
> terminate on failure of allocation, then I'll have to resort to not using
> the standard library, but using a  modified clone of it. This would be
> ironic,  as one of the motivations of his proposal in the first place is
> that people are not using the standard library.
>
> --
> 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/cc411e93-53a=
3-4b24-8e02-68fda610c15e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-53=
a3-4b24-8e02-68fda610c15e%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/CAP3wax-C-dpaf5PutO0mv2_aUObrR136c-O7N9%3DgpKCH7=
o8a3Q%40mail.gmail.com.

--0000000000009e4df705788c5195
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>It sounds like what you are suggesting is that inste=
ad of making library functions that can throw unconditionally noexcept, we:=
<div dir=3D"auto"><br></div><div dir=3D"auto">* Make them conditionally noe=
xcept if any user defined allocators used can throw, and</div><div dir=3D"a=
uto">* Make std::allocator and operator new (aka the defaults) noexcept.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">The result is the same in =
the default case; out of memory is fatal. But if you use a customize alloca=
tor that can throw, you get the current semantics.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">This sounds reasonable to me.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Have you spoke to Herb?</div><br><br><div =
class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 17, 2018, 3:16 PM  &lt;<=
a href=3D"mailto:michel.lesoinne@gmail.com">michel.lesoinne@gmail.com</a>&g=
t; 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">In P0709=
, Herb Sutter proposes a zero-overhead deterministic variation of the excep=
tion mechanism by throwing a value of a size equivalent to two pointers.<di=
v><br></div><div>I generally like the proposal a lot. I am doing HPC progra=
mming and micro-controller programming and do see a lot of benefit in squel=
ching objections to the use of exceptions.</div><div>However, when it comes=
 to the treatment of heap exhaustion and, more importantly, the impact of i=
t on the standard library, I am finding the proposal to be disturbing.</div=
><div>In section 4.3.3 Herb proposes:</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><ul><li>=C2=A0For each standard function for which alloca=
tion is the only reportable error, make the function noexcept.
(We expect this to result in making a large majority of functions in the st=
andard library noexcept,
including default and user-replaced ::operator new.)=C2=A0</li></ul></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><ul><li> For code t=
hat wants to handle heap allocation failures, provide explicit =E2=80=9Ctry=
 to allocate=E2=80=9D functions including
the existing new(nothrow)</li></ul></blockquote><div>However this approach =
is disturbing. It is essentially saying to go back to an equivalent of test=
ing an error code on return of every single call. Also because it goes agai=
nst the ideas of writing a single generic routine for an algorithm because =
it seems to imply that every time I want to write an algorithm that involve=
s a standard library function that does a memory allocation, I should write=
 both a regular version and a try_***=C2=A0 version.=C2=A0</div><div>So Her=
b wants that the vector&lt;T&gt; push_back should be noexcept while the try=
_push_back can throw.</div><div>Though, I can see the use for having a try_=
*** in places, I wonder why he does not suggest to let the allocator used m=
ake the decision? Something like:</div><div>&gt;=C2=A0<span style=3D"backgr=
ound-color:rgb(250,255,250);color:rgb(0,128,0);font-size:12px">void push_ba=
ck (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; ) ;</span><=
/div><div><span style=3D"background-color:rgb(250,255,250);color:rgb(0,128,=
0);font-size:12px"><br></span></div><div><font color=3D"#000000"><span styl=
e=3D"font-size:12px;background-color:rgb(250,255,250)">In my HPC work, I wr=
ite library in which users can supply a memory buffer that my code can use.=
 If I run out of memory, it is out of the question that the code would cras=
h. Instead it should be reported to the user that she needs to provide a bi=
gger buffer.=C2=A0 I can do that by using an allocator that throws an excep=
tion. Using a solution like I suggest above would allow to still have noexc=
ept if the user is fine with terminate being called and still allow to hand=
le cases like mine gracefully in a way that I can report to the caller as t=
hey are expecting. If the standard library always calls terminate on failur=
e of allocation, then I&#39;ll have to resort to not using the standard lib=
rary, but using a=C2=A0 modified clone of it. This would be ironic,=C2=A0 a=
s one of the motivations of his proposal in the first place is that people =
are not using the standard library.</span></font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" rel=3D"noreferrer">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/cc411e93-53a3-4b24-8e02-68fda610c15e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/cc411e93-53a3-4b24-8e02-68fda610c15e%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&quot; 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/CAP3wax-C-dpaf5PutO0mv2_aUObrR136c-O7=
N9%3DgpKCH7o8a3Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAP3wax-C-dpaf5=
PutO0mv2_aUObrR136c-O7N9%3DgpKCH7o8a3Q%40mail.gmail.com</a>.<br />

--0000000000009e4df705788c5195--

.

------=_Part_3351_221187282.1539922705763
Content-Type: multipart/alternative;
 boundary="----=_Part_3352_1889269543.1539922705764"

------=_Part_3352_1889269543.1539922705764
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

No, I have not spoken to Herb. I was looking for a way to send him a=20
feedback on his blog or somewhere else related to that proposal. The=20
closest I found is this group.

And you are right, that is what I am proposing. I think it keeps the=20
original goal intact but adds a (imo useful) customization point.
There could be a std::throwing_allocator too, if that seems to be useful to=
=20
many people.Or at least, given the idea of the polymorphic_allocator, since=
=20
C++17, a version of it that throws would be a good thing as well.

On Thursday, October 18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein Lelbach=
=20
wrote:
>
> It sounds like what you are suggesting is that instead of making library=
=20
> functions that can throw unconditionally noexcept, we:
>
> * Make them conditionally noexcept if any user defined allocators used ca=
n=20
> throw, and
> * Make std::allocator and operator new (aka the defaults) noexcept.
>
> The result is the same in the default case; out of memory is fatal. But i=
f=20
> you use a customize allocator that can throw, you get the current semanti=
cs.
>
> This sounds reasonable to me.
>
> Have you spoke to Herb?
>
>
> On Wed, Oct 17, 2018, 3:16 PM <michel....@gmail.com <javascript:>> wrote:
>
>> In P0709, Herb Sutter proposes a zero-overhead deterministic variation o=
f=20
>> the exception mechanism by throwing a value of a size equivalent to two=
=20
>> pointers.
>>
>> I generally like the proposal a lot. I am doing HPC programming and=20
>> micro-controller programming and do see a lot of benefit in squelching=
=20
>> objections to the use of exceptions.
>> However, when it comes to the treatment of heap exhaustion and, more=20
>> importantly, the impact of it on the standard library, I am finding the=
=20
>> proposal to be disturbing.
>> In section 4.3.3 Herb proposes:
>>
>>>
>>>    -  For each standard function for which allocation is the only=20
>>>    reportable error, make the function noexcept. (We expect this to res=
ult in=20
>>>    making a large majority of functions in the standard library noexcep=
t,=20
>>>    including default and user-replaced ::operator new.)=20
>>>
>>>
>>>    - For code that wants to handle heap allocation failures, provide=20
>>>    explicit =E2=80=9Ctry to allocate=E2=80=9D functions including the e=
xisting new(nothrow)
>>>
>>> However this approach is disturbing. It is essentially saying to go bac=
k=20
>> to an equivalent of testing an error code on return of every single call=
..=20
>> Also because it goes against the ideas of writing a single generic routi=
ne=20
>> for an algorithm because it seems to imply that every time I want to wri=
te=20
>> an algorithm that involves a standard library function that does a memor=
y=20
>> allocation, I should write both a regular version and a try_***  version=
..=20
>> So Herb wants that the vector<T> push_back should be noexcept while the=
=20
>> try_push_back can throw.
>> Though, I can see the use for having a try_*** in places, I wonder why h=
e=20
>> does not suggest to let the allocator used make the decision? Something=
=20
>> like:
>> > void push_back (const value_type& val) throws( can_throw_v<Alloc> ) ;
>>
>> In my HPC work, I write library in which users can supply a memory buffe=
r=20
>> that my code can use. If I run out of memory, it is out of the question=
=20
>> that the code would crash. Instead it should be reported to the user tha=
t=20
>> she needs to provide a bigger buffer.  I can do that by using an allocat=
or=20
>> that throws an exception. Using a solution like I suggest above would al=
low=20
>> to still have noexcept if the user is fine with terminate being called a=
nd=20
>> still allow to handle cases like mine gracefully in a way that I can rep=
ort=20
>> to the caller as they are expecting. If the standard library always call=
s=20
>> terminate on failure of allocation, then I'll have to resort to not usin=
g=20
>> the standard library, but using a  modified clone of it. This would be=
=20
>> ironic,  as one of the motivations of his proposal in the first place is=
=20
>> that people are not using the standard library.
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-53=
a3-4b24-8e02-68fda610c15e%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-5=
3a3-4b24-8e02-68fda610c15e%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/b701aa54-f4b6-4d9a-8980-db398aa299e4%40isocpp.or=
g.

------=_Part_3352_1889269543.1539922705764
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No, I have not spoken to Herb. I was looking for a way to =
send him a feedback on his blog or somewhere else related to that proposal.=
 The closest I found is this group.<div><br></div><div>And you are right, t=
hat is what I am proposing. I think it keeps the original goal intact but a=
dds a (imo useful) customization point.</div><div>There could be a std::thr=
owing_allocator too, if that seems to be useful to many people.Or at least,=
 given the idea of the=C2=A0<span style=3D"color: rgb(0, 0, 0); font-family=
: DejaVuSansMono, &quot;DejaVu Sans Mono&quot;, courier, monospace; font-si=
ze: 12.8px; white-space: nowrap;">polymorphic_allocator, </span><span style=
=3D"color: rgb(0, 0, 0); font-size: 12.8px; white-space: nowrap;"><font fac=
e=3D"arial, sans-serif">since C++17, a version of it that throws would be a=
 good thing as well.</font></span><br><br>On Thursday, October 18, 2018 at =
9:15:45 PM UTC-6, Bryce Adelstein Lelbach wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"auto"><div>It sounds like what you are sugges=
ting is that instead of making library functions that can throw uncondition=
ally noexcept, we:<div dir=3D"auto"><br></div><div dir=3D"auto">* Make them=
 conditionally noexcept if any user defined allocators used can throw, and<=
/div><div dir=3D"auto">* Make std::allocator and operator new (aka the defa=
ults) noexcept.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The resu=
lt is the same in the default case; out of memory is fatal. But if you use =
a customize allocator that can throw, you get the current semantics.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">This sounds reasonable to me.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">Have you spoke to Herb?<=
/div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 17, 20=
18, 3:16 PM  &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"nlXDDOYBCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">michel....@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">In P0709, Herb Sutter proposes a zero-overhe=
ad deterministic variation of the exception mechanism by throwing a value o=
f a size equivalent to two pointers.<div><br></div><div>I generally like th=
e proposal a lot. I am doing HPC programming and micro-controller programmi=
ng and do see a lot of benefit in squelching objections to the use of excep=
tions.</div><div>However, when it comes to the treatment of heap exhaustion=
 and, more importantly, the impact of it on the standard library, I am find=
ing the proposal to be disturbing.</div><div>In section 4.3.3 Herb proposes=
:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><ul><li>=C2=A0For =
each standard function for which allocation is the only reportable error, m=
ake the function noexcept.
(We expect this to result in making a large majority of functions in the st=
andard library noexcept,
including default and user-replaced ::operator new.)=C2=A0</li></ul></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><ul><li> For code t=
hat wants to handle heap allocation failures, provide explicit =E2=80=9Ctry=
 to allocate=E2=80=9D functions including
the existing new(nothrow)</li></ul></blockquote><div>However this approach =
is disturbing. It is essentially saying to go back to an equivalent of test=
ing an error code on return of every single call. Also because it goes agai=
nst the ideas of writing a single generic routine for an algorithm because =
it seems to imply that every time I want to write an algorithm that involve=
s a standard library function that does a memory allocation, I should write=
 both a regular version and a try_***=C2=A0 version.=C2=A0</div><div>So Her=
b wants that the vector&lt;T&gt; push_back should be noexcept while the try=
_push_back can throw.</div><div>Though, I can see the use for having a try_=
*** in places, I wonder why he does not suggest to let the allocator used m=
ake the decision? Something like:</div><div>&gt;=C2=A0<span style=3D"backgr=
ound-color:rgb(250,255,250);color:rgb(0,128,0);font-size:12px">void push_ba=
ck (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; ) ;</span><=
/div><div><span style=3D"background-color:rgb(250,255,250);color:rgb(0,128,=
0);font-size:12px"><br></span></div><div><font color=3D"#000000"><span styl=
e=3D"font-size:12px;background-color:rgb(250,255,250)">In my HPC work, I wr=
ite library in which users can supply a memory buffer that my code can use.=
 If I run out of memory, it is out of the question that the code would cras=
h. Instead it should be reported to the user that she needs to provide a bi=
gger buffer.=C2=A0 I can do that by using an allocator that throws an excep=
tion. Using a solution like I suggest above would allow to still have noexc=
ept if the user is fine with terminate being called and still allow to hand=
le cases like mine gracefully in a way that I can report to the caller as t=
hey are expecting. If the standard library always calls terminate on failur=
e of allocation, then I&#39;ll have to resort to not using the standard lib=
rary, but using a=C2=A0 modified clone of it. This would be ironic,=C2=A0 a=
s one of the motivations of his proposal in the first place is that people =
are not using the standard library.</span></font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" rel=3D"nofollow" target=3D"_blank" gdf-obfu=
scated-mailto=3D"nlXDDOYBCQAJ" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" rel=3D"nofollo=
w" target=3D"_blank" gdf-obfuscated-mailto=3D"nlXDDOYBCQAJ" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@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/cc411e93-53a3-4b24-8e02-68fda610c15e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cc411e93-53a3-4b24-<wbr>8e02-=
68fda610c15e%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></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&quot; 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/b701aa54-f4b6-4d9a-8980-db398aa299e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b701aa54-f4b6-4d9a-8980-db398aa299e4=
%40isocpp.org</a>.<br />

------=_Part_3352_1889269543.1539922705764--

------=_Part_3351_221187282.1539922705763--

.

------=_Part_3603_1004434621.1539970578245
Content-Type: multipart/alternative;
 boundary="----=_Part_3604_2043015965.1539970578246"

------=_Part_3604_2043015965.1539970578246
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

"No, I have not spoken to Herb. I was looking for a way to send him a=20
feedback on his blog or somewhere else related to that proposal."
Almost all papers include an email address that can be used to provide=20
feedback.  It's a paper "bug" when there is no email address included.


On Thursday, October 18, 2018 at 11:18:25 PM UTC-5, michel....@gmail.com=20
wrote:
>
> No, I have not spoken to Herb. I was looking for a way to send him a=20
> feedback on his blog or somewhere else related to that proposal. The=20
> closest I found is this group.
>
> And you are right, that is what I am proposing. I think it keeps the=20
> original goal intact but adds a (imo useful) customization point.
> There could be a std::throwing_allocator too, if that seems to be useful=
=20
> to many people.Or at least, given the idea of the polymorphic_allocator, =
since=20
> C++17, a version of it that throws would be a good thing as well.
>
> On Thursday, October 18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein Lelbac=
h=20
> wrote:
>>
>> It sounds like what you are suggesting is that instead of making library=
=20
>> functions that can throw unconditionally noexcept, we:
>>
>> * Make them conditionally noexcept if any user defined allocators used=
=20
>> can throw, and
>> * Make std::allocator and operator new (aka the defaults) noexcept.
>>
>> The result is the same in the default case; out of memory is fatal. But=
=20
>> if you use a customize allocator that can throw, you get the current=20
>> semantics.
>>
>> This sounds reasonable to me.
>>
>> Have you spoke to Herb?
>>
>>
>> On Wed, Oct 17, 2018, 3:16 PM <michel....@gmail.com> wrote:
>>
>>> In P0709, Herb Sutter proposes a zero-overhead deterministic variation=
=20
>>> of the exception mechanism by throwing a value of a size equivalent to =
two=20
>>> pointers.
>>>
>>> I generally like the proposal a lot. I am doing HPC programming and=20
>>> micro-controller programming and do see a lot of benefit in squelching=
=20
>>> objections to the use of exceptions.
>>> However, when it comes to the treatment of heap exhaustion and, more=20
>>> importantly, the impact of it on the standard library, I am finding the=
=20
>>> proposal to be disturbing.
>>> In section 4.3.3 Herb proposes:
>>>
>>>>
>>>>    -  For each standard function for which allocation is the only=20
>>>>    reportable error, make the function noexcept. (We expect this to re=
sult in=20
>>>>    making a large majority of functions in the standard library noexce=
pt,=20
>>>>    including default and user-replaced ::operator new.)=20
>>>>
>>>>
>>>>    - For code that wants to handle heap allocation failures, provide=
=20
>>>>    explicit =E2=80=9Ctry to allocate=E2=80=9D functions including the =
existing new(nothrow)
>>>>
>>>> However this approach is disturbing. It is essentially saying to go=20
>>> back to an equivalent of testing an error code on return of every singl=
e=20
>>> call. Also because it goes against the ideas of writing a single generi=
c=20
>>> routine for an algorithm because it seems to imply that every time I wa=
nt=20
>>> to write an algorithm that involves a standard library function that do=
es a=20
>>> memory allocation, I should write both a regular version and a try_*** =
=20
>>> version.=20
>>> So Herb wants that the vector<T> push_back should be noexcept while the=
=20
>>> try_push_back can throw.
>>> Though, I can see the use for having a try_*** in places, I wonder why=
=20
>>> he does not suggest to let the allocator used make the decision? Someth=
ing=20
>>> like:
>>> > void push_back (const value_type& val) throws( can_throw_v<Alloc> ) ;
>>>
>>> In my HPC work, I write library in which users can supply a memory=20
>>> buffer that my code can use. If I run out of memory, it is out of the=
=20
>>> question that the code would crash. Instead it should be reported to th=
e=20
>>> user that she needs to provide a bigger buffer.  I can do that by using=
 an=20
>>> allocator that throws an exception. Using a solution like I suggest abo=
ve=20
>>> would allow to still have noexcept if the user is fine with terminate b=
eing=20
>>> called and still allow to handle cases like mine gracefully in a way th=
at I=20
>>> can report to the caller as they are expecting. If the standard library=
=20
>>> always calls terminate on failure of allocation, then I'll have to reso=
rt=20
>>> to not using the standard library, but using a  modified clone of it. T=
his=20
>>> would be ironic,  as one of the motivations of his proposal in the firs=
t=20
>>> place is that people are not using the standard library.
>>>
>>> --=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-5=
3a3-4b24-8e02-68fda610c15e%40isocpp.org=20
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-=
53a3-4b24-8e02-68fda610c15e%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>>

--=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/c76e7e32-a6ed-4e8c-9da2-519ca31534a6%40isocpp.or=
g.

------=_Part_3604_2043015965.1539970578246
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&quot;No, I have not spoken to Herb. I was looking for a w=
ay to send him a feedback on his blog or somewhere else related to that pro=
posal.&quot;<div>Almost all papers include an email address that can be use=
d to provide feedback.=C2=A0 It&#39;s a paper &quot;bug&quot; when there is=
 no email address included.</div><div><br><br>On Thursday, October 18, 2018=
 at 11:18:25 PM UTC-5, michel....@gmail.com wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr">No, I have not spoken to Herb. I was l=
ooking for a way to send him a feedback on his blog or somewhere else relat=
ed to that proposal. The closest I found is this group.<div><br></div><div>=
And you are right, that is what I am proposing. I think it keeps the origin=
al goal intact but adds a (imo useful) customization point.</div><div>There=
 could be a std::throwing_allocator too, if that seems to be useful to many=
 people.Or at least, given the idea of the=C2=A0<span style=3D"color:rgb(0,=
0,0);font-family:DejaVuSansMono,&quot;DejaVu Sans Mono&quot;,courier,monosp=
ace;font-size:12.8px;white-space:nowrap">polymorphic_allocator, </span><spa=
n style=3D"color:rgb(0,0,0);font-size:12.8px;white-space:nowrap"><font face=
=3D"arial, sans-serif">since C++17, a version of it that throws would be a =
good thing as well.</font></span><br><br>On Thursday, October 18, 2018 at 9=
:15:45 PM UTC-6, Bryce Adelstein Lelbach wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"auto"><div>It sounds like what you are suggesting i=
s that instead of making library functions that can throw unconditionally n=
oexcept, we:<div dir=3D"auto"><br></div><div dir=3D"auto">* Make them condi=
tionally noexcept if any user defined allocators used can throw, and</div><=
div dir=3D"auto">* Make std::allocator and operator new (aka the defaults) =
noexcept.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The result is =
the same in the default case; out of memory is fatal. But if you use a cust=
omize allocator that can throw, you get the current semantics.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">This sounds reasonable to me.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Have you spoke to Herb?</div><=
br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 17, 2018, 3:=
16 PM  &lt;<a rel=3D"nofollow">michel....@gmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In P0709, Herb Sutter prop=
oses a zero-overhead deterministic variation of the exception mechanism by =
throwing a value of a size equivalent to two pointers.<div><br></div><div>I=
 generally like the proposal a lot. I am doing HPC programming and micro-co=
ntroller programming and do see a lot of benefit in squelching objections t=
o the use of exceptions.</div><div>However, when it comes to the treatment =
of heap exhaustion and, more importantly, the impact of it on the standard =
library, I am finding the proposal to be disturbing.</div><div>In section 4=
..3.3 Herb proposes:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<ul><li>=C2=A0For each standard function for which allocation is the only r=
eportable error, make the function noexcept.
(We expect this to result in making a large majority of functions in the st=
andard library noexcept,
including default and user-replaced ::operator new.)=C2=A0</li></ul></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><ul><li> For code t=
hat wants to handle heap allocation failures, provide explicit =E2=80=9Ctry=
 to allocate=E2=80=9D functions including
the existing new(nothrow)</li></ul></blockquote><div>However this approach =
is disturbing. It is essentially saying to go back to an equivalent of test=
ing an error code on return of every single call. Also because it goes agai=
nst the ideas of writing a single generic routine for an algorithm because =
it seems to imply that every time I want to write an algorithm that involve=
s a standard library function that does a memory allocation, I should write=
 both a regular version and a try_***=C2=A0 version.=C2=A0</div><div>So Her=
b wants that the vector&lt;T&gt; push_back should be noexcept while the try=
_push_back can throw.</div><div>Though, I can see the use for having a try_=
*** in places, I wonder why he does not suggest to let the allocator used m=
ake the decision? Something like:</div><div>&gt;=C2=A0<span style=3D"backgr=
ound-color:rgb(250,255,250);color:rgb(0,128,0);font-size:12px">void push_ba=
ck (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; ) ;</span><=
/div><div><span style=3D"background-color:rgb(250,255,250);color:rgb(0,128,=
0);font-size:12px"><br></span></div><div><font color=3D"#000000"><span styl=
e=3D"font-size:12px;background-color:rgb(250,255,250)">In my HPC work, I wr=
ite library in which users can supply a memory buffer that my code can use.=
 If I run out of memory, it is out of the question that the code would cras=
h. Instead it should be reported to the user that she needs to provide a bi=
gger buffer.=C2=A0 I can do that by using an allocator that throws an excep=
tion. Using a solution like I suggest above would allow to still have noexc=
ept if the user is fine with terminate being called and still allow to hand=
le cases like mine gracefully in a way that I can report to the caller as t=
hey are expecting. If the standard library always calls terminate on failur=
e of allocation, then I&#39;ll have to resort to not using the standard lib=
rary, but using a=C2=A0 modified clone of it. This would be ironic,=C2=A0 a=
s one of the motivations of his proposal in the first place is that people =
are not using the standard library.</span></font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@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/cc411e93-53a3-4b24-8e02-68fda610c15e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cc411e93-53a3-4b24-<wbr>8e02-=
68fda610c15e%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div></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&quot; 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/c76e7e32-a6ed-4e8c-9da2-519ca31534a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c76e7e32-a6ed-4e8c-9da2-519ca31534a6=
%40isocpp.org</a>.<br />

------=_Part_3604_2043015965.1539970578246--

------=_Part_3603_1004434621.1539970578245--

.

------=_Part_3688_1280911328.1539974273106
Content-Type: multipart/alternative;
 boundary="----=_Part_3689_1626592930.1539974273106"

------=_Part_3689_1626592930.1539974273106
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You are right. Wasn't sure it's the most appropriate channel, but I will=20
email him. Thanks.

On Friday, October 19, 2018 at 11:36:18 AM UTC-6, Ben Craig wrote:
>
> "No, I have not spoken to Herb. I was looking for a way to send him a=20
> feedback on his blog or somewhere else related to that proposal."
> Almost all papers include an email address that can be used to provide=20
> feedback.  It's a paper "bug" when there is no email address included.
>
>
> On Thursday, October 18, 2018 at 11:18:25 PM UTC-5, michel....@gmail.com=
=20
> wrote:
>>
>> No, I have not spoken to Herb. I was looking for a way to send him a=20
>> feedback on his blog or somewhere else related to that proposal. The=20
>> closest I found is this group.
>>
>> And you are right, that is what I am proposing. I think it keeps the=20
>> original goal intact but adds a (imo useful) customization point.
>> There could be a std::throwing_allocator too, if that seems to be useful=
=20
>> to many people.Or at least, given the idea of the polymorphic_allocator,=
 since=20
>> C++17, a version of it that throws would be a good thing as well.
>>
>> On Thursday, October 18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein=20
>> Lelbach wrote:
>>>
>>> It sounds like what you are suggesting is that instead of making librar=
y=20
>>> functions that can throw unconditionally noexcept, we:
>>>
>>> * Make them conditionally noexcept if any user defined allocators used=
=20
>>> can throw, and
>>> * Make std::allocator and operator new (aka the defaults) noexcept.
>>>
>>> The result is the same in the default case; out of memory is fatal. But=
=20
>>> if you use a customize allocator that can throw, you get the current=20
>>> semantics.
>>>
>>> This sounds reasonable to me.
>>>
>>> Have you spoke to Herb?
>>>
>>>
>>> On Wed, Oct 17, 2018, 3:16 PM <michel....@gmail.com> wrote:
>>>
>>>> In P0709, Herb Sutter proposes a zero-overhead deterministic variation=
=20
>>>> of the exception mechanism by throwing a value of a size equivalent to=
 two=20
>>>> pointers.
>>>>
>>>> I generally like the proposal a lot. I am doing HPC programming and=20
>>>> micro-controller programming and do see a lot of benefit in squelching=
=20
>>>> objections to the use of exceptions.
>>>> However, when it comes to the treatment of heap exhaustion and, more=
=20
>>>> importantly, the impact of it on the standard library, I am finding th=
e=20
>>>> proposal to be disturbing.
>>>> In section 4.3.3 Herb proposes:
>>>>
>>>>>
>>>>>    -  For each standard function for which allocation is the only=20
>>>>>    reportable error, make the function noexcept. (We expect this to r=
esult in=20
>>>>>    making a large majority of functions in the standard library noexc=
ept,=20
>>>>>    including default and user-replaced ::operator new.)=20
>>>>>
>>>>>
>>>>>    - For code that wants to handle heap allocation failures, provide=
=20
>>>>>    explicit =E2=80=9Ctry to allocate=E2=80=9D functions including the=
 existing new(nothrow)
>>>>>
>>>>> However this approach is disturbing. It is essentially saying to go=
=20
>>>> back to an equivalent of testing an error code on return of every sing=
le=20
>>>> call. Also because it goes against the ideas of writing a single gener=
ic=20
>>>> routine for an algorithm because it seems to imply that every time I w=
ant=20
>>>> to write an algorithm that involves a standard library function that d=
oes a=20
>>>> memory allocation, I should write both a regular version and a try_***=
 =20
>>>> version.=20
>>>> So Herb wants that the vector<T> push_back should be noexcept while th=
e=20
>>>> try_push_back can throw.
>>>> Though, I can see the use for having a try_*** in places, I wonder why=
=20
>>>> he does not suggest to let the allocator used make the decision? Somet=
hing=20
>>>> like:
>>>> > void push_back (const value_type& val) throws( can_throw_v<Alloc> ) =
;
>>>>
>>>> In my HPC work, I write library in which users can supply a memory=20
>>>> buffer that my code can use. If I run out of memory, it is out of the=
=20
>>>> question that the code would crash. Instead it should be reported to t=
he=20
>>>> user that she needs to provide a bigger buffer.  I can do that by usin=
g an=20
>>>> allocator that throws an exception. Using a solution like I suggest ab=
ove=20
>>>> would allow to still have noexcept if the user is fine with terminate =
being=20
>>>> called and still allow to handle cases like mine gracefully in a way t=
hat I=20
>>>> can report to the caller as they are expecting. If the standard librar=
y=20
>>>> always calls terminate on failure of allocation, then I'll have to res=
ort=20
>>>> to not using the standard library, but using a  modified clone of it. =
This=20
>>>> would be ironic,  as one of the motivations of his proposal in the fir=
st=20
>>>> place is that people are not using the standard library.
>>>>
>>>> --=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> To view this discussion on the web visit=20
>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-=
53a3-4b24-8e02-68fda610c15e%40isocpp.org=20
>>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93=
-53a3-4b24-8e02-68fda610c15e%40isocpp.org?utm_medium=3Demail&utm_source=3Df=
ooter>
>>>> .
>>>>
>>>

--=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/70908db4-8cc7-41b2-b490-45119b8b5c5f%40isocpp.or=
g.

------=_Part_3689_1626592930.1539974273106
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You are right. Wasn&#39;t sure it&#39;s the most appropria=
te channel, but I will email him. Thanks.<div><br>On Friday, October 19, 20=
18 at 11:36:18 AM UTC-6, Ben Craig wrote:<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">&quot;No, I have not spoken to Herb. I was look=
ing for a way to send him a feedback on his blog or somewhere else related =
to that proposal.&quot;<div>Almost all papers include an email address that=
 can be used to provide feedback.=C2=A0 It&#39;s a paper &quot;bug&quot; wh=
en there is no email address included.</div><div><br><br>On Thursday, Octob=
er 18, 2018 at 11:18:25 PM UTC-5, <a>michel....@gmail.com</a> wrote:<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">No, I have not spoken to =
Herb. I was looking for a way to send him a feedback on his blog or somewhe=
re else related to that proposal. The closest I found is this group.<div><b=
r></div><div>And you are right, that is what I am proposing. I think it kee=
ps the original goal intact but adds a (imo useful) customization point.</d=
iv><div>There could be a std::throwing_allocator too, if that seems to be u=
seful to many people.Or at least, given the idea of the=C2=A0<span style=3D=
"color:rgb(0,0,0);font-family:DejaVuSansMono,&quot;DejaVu Sans Mono&quot;,c=
ourier,monospace;font-size:12.8px;white-space:nowrap">polymorphic_allocator=
, </span><span style=3D"color:rgb(0,0,0);font-size:12.8px;white-space:nowra=
p"><font face=3D"arial, sans-serif">since C++17, a version of it that throw=
s would be a good thing as well.</font></span><br><br>On Thursday, October =
18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein Lelbach wrote:<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"auto"><div>It sounds like what you are=
 suggesting is that instead of making library functions that can throw unco=
nditionally noexcept, we:<div dir=3D"auto"><br></div><div dir=3D"auto">* Ma=
ke them conditionally noexcept if any user defined allocators used can thro=
w, and</div><div dir=3D"auto">* Make std::allocator and operator new (aka t=
he defaults) noexcept.</div><div dir=3D"auto"><br></div><div dir=3D"auto">T=
he result is the same in the default case; out of memory is fatal. But if y=
ou use a customize allocator that can throw, you get the current semantics.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">This sounds reasonable =
to me.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Have you spoke to=
 Herb?</div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct=
 17, 2018, 3:16 PM  &lt;<a rel=3D"nofollow">michel....@gmail.com</a>&gt; wr=
ote:<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">In P0709, Her=
b Sutter proposes a zero-overhead deterministic variation of the exception =
mechanism by throwing a value of a size equivalent to two pointers.<div><br=
></div><div>I generally like the proposal a lot. I am doing HPC programming=
 and micro-controller programming and do see a lot of benefit in squelching=
 objections to the use of exceptions.</div><div>However, when it comes to t=
he treatment of heap exhaustion and, more importantly, the impact of it on =
the standard library, I am finding the proposal to be disturbing.</div><div=
>In section 4.3.3 Herb proposes:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><ul><li>=C2=A0For each standard function for which allocation =
is the only reportable error, make the function noexcept.
(We expect this to result in making a large majority of functions in the st=
andard library noexcept,
including default and user-replaced ::operator new.)=C2=A0</li></ul></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><ul><li> For code t=
hat wants to handle heap allocation failures, provide explicit =E2=80=9Ctry=
 to allocate=E2=80=9D functions including
the existing new(nothrow)</li></ul></blockquote><div>However this approach =
is disturbing. It is essentially saying to go back to an equivalent of test=
ing an error code on return of every single call. Also because it goes agai=
nst the ideas of writing a single generic routine for an algorithm because =
it seems to imply that every time I want to write an algorithm that involve=
s a standard library function that does a memory allocation, I should write=
 both a regular version and a try_***=C2=A0 version.=C2=A0</div><div>So Her=
b wants that the vector&lt;T&gt; push_back should be noexcept while the try=
_push_back can throw.</div><div>Though, I can see the use for having a try_=
*** in places, I wonder why he does not suggest to let the allocator used m=
ake the decision? Something like:</div><div>&gt;=C2=A0<span style=3D"backgr=
ound-color:rgb(250,255,250);color:rgb(0,128,0);font-size:12px">void push_ba=
ck (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; ) ;</span><=
/div><div><span style=3D"background-color:rgb(250,255,250);color:rgb(0,128,=
0);font-size:12px"><br></span></div><div><font color=3D"#000000"><span styl=
e=3D"font-size:12px;background-color:rgb(250,255,250)">In my HPC work, I wr=
ite library in which users can supply a memory buffer that my code can use.=
 If I run out of memory, it is out of the question that the code would cras=
h. Instead it should be reported to the user that she needs to provide a bi=
gger buffer.=C2=A0 I can do that by using an allocator that throws an excep=
tion. Using a solution like I suggest above would allow to still have noexc=
ept if the user is fine with terminate being called and still allow to hand=
le cases like mine gracefully in a way that I can report to the caller as t=
hey are expecting. If the standard library always calls terminate on failur=
e of allocation, then I&#39;ll have to resort to not using the standard lib=
rary, but using a=C2=A0 modified clone of it. This would be ironic,=C2=A0 a=
s one of the motivations of his proposal in the first place is that people =
are not using the standard library.</span></font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@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/cc411e93-53a3-4b24-8e02-68fda610c15e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cc411e93-53a3-4b24-<wbr>8e02-=
68fda610c15e%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div></div></blockquote></div></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&quot; 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/70908db4-8cc7-41b2-b490-45119b8b5c5f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/70908db4-8cc7-41b2-b490-45119b8b5c5f=
%40isocpp.org</a>.<br />

------=_Part_3689_1626592930.1539974273106--

------=_Part_3688_1280911328.1539974273106--

.

------=_Part_3811_557098665.1539984438447
Content-Type: multipart/alternative;
 boundary="----=_Part_3812_836467217.1539984438447"

------=_Part_3812_836467217.1539984438447
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



2018. okt=C3=B3ber 17., szerda 21:16:02 UTC+2 id=C5=91pontban michel....@gm=
ail.com a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> However this approach is disturbing. It is essentially saying to go back=
=20
> to an equivalent of testing an error code on return of every single call.=
=20
> Also because it goes against the ideas of writing a single generic routin=
e=20
> for an algorithm because it seems to imply that every time I want to writ=
e=20
> an algorithm that involves a standard library function that does a memory=
=20
> allocation, I should write both a regular version and a try_***  version.=
=20
> So Herb wants that the vector<T> push_back should be noexcept while the=
=20
> try_push_back can throw.
> Though, I can see the use for having a try_*** in places, I wonder why he=
=20
> does not suggest to let the allocator used make the decision?
>

I didn't read the proposal (and it is a long way from final so by the time=
=20
I do it may have changed that part ;)   so just my general thoughts:

The OOM handling as we have it today is indeed suboptimal for many many=20
environmants. And making all those functions nothrow looks like progress in=
=20
the good direction. The throwing approach is only good for those who=20
actually handle it and keep the program going. My past experience on=20
several platforms is that the program just never survived such an attempt,=
=20
it failed in some OS call or just got killed. The tactics to have some=20
pre-reserved memory and release that to manage the small portion of clean=
=20
exit was futile too, whatever caused the OOM condition in the first place=
=20
grabbed the chunk. =20

Wherever I can I arrange OOM as a fatal failure with direct terminate.=20
(maybe would allow  a "stall" option in the new handler if all memory was=
=20
obtained through that, but it realistically isn't). =20

The places where I really expect OOM and want retry are really rare, and=20
belong to a special case of grabbing some big chunk, amount subject to=20
available memory. For what I'd really appreciate a proper interface without=
=20
throwing, that I could supply with a callback for haggling, and would give=
=20
me the memory chunk and the brokered size.=20

And to help out the code that actually likes the current interface and=20
wants to deal with catching bad_alloc, I'm positive we can think up several=
=20
ways from specific interface additions (i.e vector does not really need to=
=20
duplicate all the interface, just have a try_reserve) or some control flags=
=20
at global/thread/object level to alter behavior. If the replacable=20
new_handler is not enough.=20



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7946c93f-6bbd-42e4-b037-2784e93e537a%40isocpp.or=
g.

------=_Part_3812_836467217.1539984438447
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>2018. okt=C3=B3ber 17., szerda 21:16:02 UTC+2 id=
=C5=91pontban michel....@gmail.com a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">However this approac=
h is disturbing. It is essentially saying to go back to an equivalent of te=
sting an error code on return of every single call. Also because it goes ag=
ainst the ideas of writing a single generic routine for an algorithm becaus=
e it seems to imply that every time I want to write an algorithm that invol=
ves a standard library function that does a memory allocation, I should wri=
te both a regular version and a try_***=C2=A0 version.=C2=A0<div>So Herb wa=
nts that the vector&lt;T&gt; push_back should be noexcept while the try_pus=
h_back can throw.</div><div>Though, I can see the use for having a try_*** =
in places, I wonder why he does not suggest to let the allocator used make =
the decision?</div></div></blockquote><div><br></div><div>I didn&#39;t read=
 the proposal (and it is a long way from final so by the time I do it may h=
ave changed that part ;)=C2=A0=C2=A0 so just my general thoughts:</div><div=
><br></div><div>The OOM handling as we have it today is indeed suboptimal f=
or many many environmants. And making all those functions nothrow looks lik=
e progress in the good direction. The throwing approach is only good for th=
ose who actually handle it and keep the program going. My past experience o=
n several platforms is that the program just never survived such an attempt=
, it failed in some OS call or just got killed. The tactics to have some pr=
e-reserved memory and release that to manage the small portion of clean exi=
t was futile too, whatever caused the OOM condition in the first place grab=
bed the chunk.=C2=A0 <br></div><div><br></div><div>Wherever I can I arrange=
 OOM as a fatal failure with direct terminate. (maybe would allow=C2=A0 a &=
quot;stall&quot; option in the new handler if all memory was obtained throu=
gh that, but it realistically isn&#39;t).=C2=A0=C2=A0</div><div><br></div><=
div>The places where I really expect OOM and want retry are really rare, an=
d belong to a special case of grabbing some big chunk, amount subject to av=
ailable memory. For what I&#39;d really appreciate a proper interface witho=
ut throwing, that I could supply with a callback for haggling, and would gi=
ve me the memory chunk and the brokered size. <br></div><div><br></div><div=
>And to help out the code that actually likes the current interface and wan=
ts to deal with catching bad_alloc, I&#39;m positive we can think up severa=
l ways from specific interface additions (i.e vector does not really need t=
o duplicate all the interface, just have a try_reserve) or some control fla=
gs at global/thread/object level to alter behavior. If the replacable new_h=
andler is not enough. <br></div><div><br></div><div><br></div><div><br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/7946c93f-6bbd-42e4-b037-2784e93e537a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7946c93f-6bbd-42e4-b037-2784e93e537a=
%40isocpp.org</a>.<br />

------=_Part_3812_836467217.1539984438447--

------=_Part_3811_557098665.1539984438447--

.

--000000000000f5e68705789c6da3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Adding Herb

On Fri, Oct 19, 2018, 12:18 AM <michel.lesoinne@gmail.com> wrote:

> No, I have not spoken to Herb. I was looking for a way to send him a
> feedback on his blog or somewhere else related to that proposal. The
> closest I found is this group.
>
> And you are right, that is what I am proposing. I think it keeps the
> original goal intact but adds a (imo useful) customization point.
> There could be a std::throwing_allocator too, if that seems to be useful
> to many people.Or at least, given the idea of the polymorphic_allocator, =
since
> C++17, a version of it that throws would be a good thing as well.
>
> On Thursday, October 18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein Lelbac=
h
> wrote:
>>
>> It sounds like what you are suggesting is that instead of making library
>> functions that can throw unconditionally noexcept, we:
>>
>> * Make them conditionally noexcept if any user defined allocators used
>> can throw, and
>> * Make std::allocator and operator new (aka the defaults) noexcept.
>>
>> The result is the same in the default case; out of memory is fatal. But
>> if you use a customize allocator that can throw, you get the current
>> semantics.
>>
>> This sounds reasonable to me.
>>
>> Have you spoke to Herb?
>>
>>
>> On Wed, Oct 17, 2018, 3:16 PM <michel....@gmail.com> wrote:
>>
>>> In P0709, Herb Sutter proposes a zero-overhead deterministic variation
>>> of the exception mechanism by throwing a value of a size equivalent to =
two
>>> pointers.
>>>
>>> I generally like the proposal a lot. I am doing HPC programming and
>>> micro-controller programming and do see a lot of benefit in squelching
>>> objections to the use of exceptions.
>>> However, when it comes to the treatment of heap exhaustion and, more
>>> importantly, the impact of it on the standard library, I am finding the
>>> proposal to be disturbing.
>>> In section 4.3.3 Herb proposes:
>>>
>>>>
>>>>    -  For each standard function for which allocation is the only
>>>>    reportable error, make the function noexcept. (We expect this to re=
sult in
>>>>    making a large majority of functions in the standard library noexce=
pt,
>>>>    including default and user-replaced ::operator new.)
>>>>
>>>>
>>>>    - For code that wants to handle heap allocation failures, provide
>>>>    explicit =E2=80=9Ctry to allocate=E2=80=9D functions including the =
existing new(nothrow)
>>>>
>>>> However this approach is disturbing. It is essentially saying to go
>>> back to an equivalent of testing an error code on return of every singl=
e
>>> call. Also because it goes against the ideas of writing a single generi=
c
>>> routine for an algorithm because it seems to imply that every time I wa=
nt
>>> to write an algorithm that involves a standard library function that do=
es a
>>> memory allocation, I should write both a regular version and a try_***
>>> version.
>>> So Herb wants that the vector<T> push_back should be noexcept while the
>>> try_push_back can throw.
>>> Though, I can see the use for having a try_*** in places, I wonder why
>>> he does not suggest to let the allocator used make the decision? Someth=
ing
>>> like:
>>> > void push_back (const value_type& val) throws( can_throw_v<Alloc> ) ;
>>>
>>> In my HPC work, I write library in which users can supply a memory
>>> buffer that my code can use. If I run out of memory, it is out of the
>>> question that the code would crash. Instead it should be reported to th=
e
>>> user that she needs to provide a bigger buffer.  I can do that by using=
 an
>>> allocator that throws an exception. Using a solution like I suggest abo=
ve
>>> would allow to still have noexcept if the user is fine with terminate b=
eing
>>> called and still allow to handle cases like mine gracefully in a way th=
at I
>>> can report to the caller as they are expecting. If the standard library
>>> always calls terminate on failure of allocation, then I'll have to reso=
rt
>>> to not using the standard library, but using a  modified clone of it. T=
his
>>> would be ironic,  as one of the motivations of his proposal in the firs=
t
>>> place is that people are not using the standard library.
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-5=
3a3-4b24-8e02-68fda610c15e%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-=
53a3-4b24-8e02-68fda610c15e%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
> 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/b701aa54-f4b=
6-4d9a-8980-db398aa299e4%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b701aa54-f4=
b6-4d9a-8980-db398aa299e4%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/CAP3wax_iN%2BObzNXg-ONWMkUHR3e_ZDMAdw_EOEf3eH1Ck=
cHu-Q%40mail.gmail.com.

--000000000000f5e68705789c6da3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Adding Herb</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Fri, Oct 19, 2018, 12:18 AM  &lt;<a href=3D"mailto:michel.lesoi=
nne@gmail.com">michel.lesoinne@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">No, I have not spoken to Herb. I was =
looking for a way to send him a feedback on his blog or somewhere else rela=
ted to that proposal. The closest I found is this group.<div><br></div><div=
>And you are right, that is what I am proposing. I think it keeps the origi=
nal goal intact but adds a (imo useful) customization point.</div><div>Ther=
e could be a std::throwing_allocator too, if that seems to be useful to man=
y people.Or at least, given the idea of the=C2=A0<span style=3D"color:rgb(0=
,0,0);font-family:DejaVuSansMono,&quot;DejaVu Sans Mono&quot;,courier,monos=
pace;font-size:12.8px;white-space:nowrap">polymorphic_allocator, </span><sp=
an style=3D"color:rgb(0,0,0);font-size:12.8px;white-space:nowrap"><font fac=
e=3D"arial, sans-serif">since C++17, a version of it that throws would be a=
 good thing as well.</font></span><br><br>On Thursday, October 18, 2018 at =
9:15:45 PM UTC-6, Bryce Adelstein Lelbach wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"auto"><div>It sounds like what you are suggesting =
is that instead of making library functions that can throw unconditionally =
noexcept, we:<div dir=3D"auto"><br></div><div dir=3D"auto">* Make them cond=
itionally noexcept if any user defined allocators used can throw, and</div>=
<div dir=3D"auto">* Make std::allocator and operator new (aka the defaults)=
 noexcept.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The result is=
 the same in the default case; out of memory is fatal. But if you use a cus=
tomize allocator that can throw, you get the current semantics.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">This sounds reasonable to me.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Have you spoke to Herb?</div>=
<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 17, 2018, 3=
:16 PM  &lt;<a rel=3D"nofollow noreferrer">michel....@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In P0709, Herb=
 Sutter proposes a zero-overhead deterministic variation of the exception m=
echanism by throwing a value of a size equivalent to two pointers.<div><br>=
</div><div>I generally like the proposal a lot. I am doing HPC programming =
and micro-controller programming and do see a lot of benefit in squelching =
objections to the use of exceptions.</div><div>However, when it comes to th=
e treatment of heap exhaustion and, more importantly, the impact of it on t=
he standard library, I am finding the proposal to be disturbing.</div><div>=
In section 4.3.3 Herb proposes:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><ul><li>=C2=A0For each standard function for which allocation i=
s the only reportable error, make the function noexcept.
(We expect this to result in making a large majority of functions in the st=
andard library noexcept,
including default and user-replaced ::operator new.)=C2=A0</li></ul></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><ul><li> For code t=
hat wants to handle heap allocation failures, provide explicit =E2=80=9Ctry=
 to allocate=E2=80=9D functions including
the existing new(nothrow)</li></ul></blockquote><div>However this approach =
is disturbing. It is essentially saying to go back to an equivalent of test=
ing an error code on return of every single call. Also because it goes agai=
nst the ideas of writing a single generic routine for an algorithm because =
it seems to imply that every time I want to write an algorithm that involve=
s a standard library function that does a memory allocation, I should write=
 both a regular version and a try_***=C2=A0 version.=C2=A0</div><div>So Her=
b wants that the vector&lt;T&gt; push_back should be noexcept while the try=
_push_back can throw.</div><div>Though, I can see the use for having a try_=
*** in places, I wonder why he does not suggest to let the allocator used m=
ake the decision? Something like:</div><div>&gt;=C2=A0<span style=3D"backgr=
ound-color:rgb(250,255,250);color:rgb(0,128,0);font-size:12px">void push_ba=
ck (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; ) ;</span><=
/div><div><span style=3D"background-color:rgb(250,255,250);color:rgb(0,128,=
0);font-size:12px"><br></span></div><div><font color=3D"#000000"><span styl=
e=3D"font-size:12px;background-color:rgb(250,255,250)">In my HPC work, I wr=
ite library in which users can supply a memory buffer that my code can use.=
 If I run out of memory, it is out of the question that the code would cras=
h. Instead it should be reported to the user that she needs to provide a bi=
gger buffer.=C2=A0 I can do that by using an allocator that throws an excep=
tion. Using a solution like I suggest above would allow to still have noexc=
ept if the user is fine with terminate being called and still allow to hand=
le cases like mine gracefully in a way that I can report to the caller as t=
hey are expecting. If the standard library always calls terminate on failur=
e of allocation, then I&#39;ll have to resort to not using the standard lib=
rary, but using a=C2=A0 modified clone of it. This would be ironic,=C2=A0 a=
s one of the motivations of his proposal in the first place is that people =
are not using the standard library.</span></font></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow noreferrer">std-pr.=
...@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/cc411e93-53a3-4b24-8e02-68fda610c15e%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow no=
referrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40isocpp.org</a>.<br>
</blockquote></div></div></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&quot; 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" rel=3D"noreferrer">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/b701aa54-f4b6-4d9a-8980-db398aa299e4%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/b701aa54-f4b6-4d9a-8980-db398aa299e4%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAP3wax_iN%2BObzNXg-ONWMkUHR3e_ZDMAdw=
_EOEf3eH1CkcHu-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAP3wax_iN%2BOb=
zNXg-ONWMkUHR3e_ZDMAdw_EOEf3eH1CkcHu-Q%40mail.gmail.com</a>.<br />

--000000000000f5e68705789c6da3--

.

This is a multipart message in MIME format.

------=_NextPart_000_0089_01D467CE.26E039E0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ack: Got it, thanks! Will merge with other feedback and discussions as they=
 happen over the coming meetings=E2=80=A6

=20

=20

From: Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com>=20
Sent: Friday, October 19, 2018 3:29 PM
To: std-proposals@isocpp.org
Cc: Herb Sutter <herb.sutter@gmail.com>
Subject: Re: [std-proposals] P0709 Heap exhaustion and try_... for standard=
 library.

=20

Adding Herb

=20

On Fri, Oct 19, 2018, 12:18 AM <michel.lesoinne@gmail.com <mailto:michel.le=
soinne@gmail.com> > wrote:

No, I have not spoken to Herb. I was looking for a way to send him a feedba=
ck on his blog or somewhere else related to that proposal. The closest I fo=
und is this group.

=20

And you are right, that is what I am proposing. I think it keeps the origin=
al goal intact but adds a (imo useful) customization point.

There could be a std::throwing_allocator too, if that seems to be useful to=
 many people.Or at least, given the idea of the polymorphic_allocator, sinc=
e C++17, a version of it that throws would be a good thing as well.

On Thursday, October 18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein Lelbach =
wrote:

It sounds like what you are suggesting is that instead of making library fu=
nctions that can throw unconditionally noexcept, we:

=20

* Make them conditionally noexcept if any user defined allocators used can =
throw, and

* Make std::allocator and operator new (aka the defaults) noexcept.

=20

The result is the same in the default case; out of memory is fatal. But if =
you use a customize allocator that can throw, you get the current semantics=
..

=20

This sounds reasonable to me.

=20

Have you spoke to Herb?

=20

On Wed, Oct 17, 2018, 3:16 PM <michel....@gmail.com <mailto:michel....@gmai=
l.com> > wrote:

In P0709, Herb Sutter proposes a zero-overhead deterministic variation of t=
he exception mechanism by throwing a value of a size equivalent to two poin=
ters.

=20

I generally like the proposal a lot. I am doing HPC programming and micro-c=
ontroller programming and do see a lot of benefit in squelching objections =
to the use of exceptions.

However, when it comes to the treatment of heap exhaustion and, more import=
antly, the impact of it on the standard library, I am finding the proposal =
to be disturbing.

In section 4.3.3 Herb proposes:

*  For each standard function for which allocation is the only reportable e=
rror, make the function noexcept. (We expect this to result in making a lar=
ge majority of functions in the standard library noexcept, including defaul=
t and user-replaced ::operator new.)=20

* For code that wants to handle heap allocation failures, provide explicit =
=E2=80=9Ctry to allocate=E2=80=9D functions including the existing new(noth=
row)

However this approach is disturbing. It is essentially saying to go back to=
 an equivalent of testing an error code on return of every single call. Als=
o because it goes against the ideas of writing a single generic routine for=
 an algorithm because it seems to imply that every time I want to write an =
algorithm that involves a standard library function that does a memory allo=
cation, I should write both a regular version and a try_***  version.=20

So Herb wants that the vector<T> push_back should be noexcept while the try=
_push_back can throw.

Though, I can see the use for having a try_*** in places, I wonder why he d=
oes not suggest to let the allocator used make the decision? Something like=
:

> void push_back (const value_type& val) throws( can_throw_v<Alloc> ) ;

=20

In my HPC work, I write library in which users can supply a memory buffer t=
hat my code can use. If I run out of memory, it is out of the question that=
 the code would crash. Instead it should be reported to the user that she n=
eeds to provide a bigger buffer.  I can do that by using an allocator that =
throws an exception. Using a solution like I suggest above would allow to s=
till have noexcept if the user is fine with terminate being called and stil=
l allow to handle cases like mine gracefully in a way that I can report to =
the caller as they are expecting. If the standard library always calls term=
inate on failure of allocation, then I'll have to resort to not using the s=
tandard library, but using a  modified clone of it. This would be ironic,  =
as one of the motivations of his proposal in the first place is that people=
 are not using the standard library.

--=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-proposal...@isocpp.org <mailto:std-proposal...@isocpp.org> .
To post to this group, send email to std-pr...@isocpp.org <mailto:std-pr...=
@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15e%40isocpp.or=
g <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-53=
a3-4b24-8e02-68fda610c15e%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 <mailto:std-proposals+unsubscr=
ibe@isocpp.org> .
To post to this group, send email to std-proposals@isocpp.org <mailto:std-p=
roposals@isocpp.org> .
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b701aa54-f4b6-4d9a-8980-db398aa299e4%40isocpp.or=
g <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b701aa54-f4=
b6-4d9a-8980-db398aa299e4%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/008801d46808%24d33a08d0%2479ae1a70%24%40gmail.co=
m.

------=_NextPart_000_0089_01D467CE.26E039E0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D"Microsoft=
 Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
 {font-family:Courier;
 panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
 {font-family:Wingdings;
 panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
 {font-family:"Cambria Math";
 panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
 {font-family:Calibri;
 panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
 {margin:0in;
 margin-bottom:.0001pt;
 font-size:11.0pt;
 font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
 {mso-style-priority:99;
 color:blue;
 text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
 {mso-style-priority:99;
 color:purple;
 text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
 {mso-style-name:msonormal;
 mso-margin-top-alt:auto;
 margin-right:0in;
 mso-margin-bottom-alt:auto;
 margin-left:0in;
 font-size:11.0pt;
 font-family:"Calibri",sans-serif;}
span.EmailStyle20
 {mso-style-type:personal-reply;
 font-family:"Calibri",sans-serif;}
..MsoChpDefault
 {mso-style-type:export-only;
 font-family:"Calibri",sans-serif;}
@page WordSection1
 {size:8.5in 11.0in;
 margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
 {page:WordSection1;}
/* List Definitions */
@list l0
 {mso-list-id:296766960;
 mso-list-template-ids:1284392922;}
@list l0:level1
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=B7;
 mso-level-tab-stop:.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Symbol;}
@list l0:level2
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:1.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:"Courier New";
 mso-bidi-font-family:"Times New Roman";}
@list l0:level3
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:1.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l0:level4
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:2.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l0:level5
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:2.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l0:level6
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:3.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l0:level7
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:3.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l0:level8
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:4.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l0:level9
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:4.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1
 {mso-list-id:728303410;
 mso-list-template-ids:-2062779360;}
@list l1:level1
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=B7;
 mso-level-tab-stop:.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Symbol;}
@list l1:level2
 {mso-level-number-format:bullet;
 mso-level-text:o;
 mso-level-tab-stop:1.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:"Courier New";
 mso-bidi-font-family:"Times New Roman";}
@list l1:level3
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:1.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1:level4
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:2.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1:level5
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:2.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1:level6
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:3.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1:level7
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:3.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1:level8
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:4.0in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
@list l1:level9
 {mso-level-number-format:bullet;
 mso-level-text:=EF=82=A7;
 mso-level-tab-stop:4.5in;
 mso-level-number-position:left;
 text-indent:-.25in;
 mso-ansi-font-size:10.0pt;
 font-family:Wingdings;}
ol
 {margin-bottom:0in;}
ul
 {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Ack: Got it, tha=
nks! Will merge with other feedback and discussions as they happen over the=
 coming meetings=E2=80=A6<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div style=3D'border:none;=
border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'=
border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p cl=
ass=3DMsoNormal><b>From:</b> Bryce Adelstein Lelbach aka wash &lt;brycelelb=
ach@gmail.com&gt; <br><b>Sent:</b> Friday, October 19, 2018 3:29 PM<br><b>T=
o:</b> std-proposals@isocpp.org<br><b>Cc:</b> Herb Sutter &lt;herb.sutter@g=
mail.com&gt;<br><b>Subject:</b> Re: [std-proposals] P0709 Heap exhaustion a=
nd try_... for standard library.<o:p></o:p></p></div></div><p class=3DMsoNo=
rmal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>Adding Herb<o:p></o:p><=
/p></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p class=3DMso=
Normal>On Fri, Oct 19, 2018, 12:18 AM &lt;<a href=3D"mailto:michel.lesoinne=
@gmail.com">michel.lesoinne@gmail.com</a>&gt; wrote:<o:p></o:p></p></div><b=
lockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in =
0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=3DMsoNormal=
>No, I have not spoken to Herb. I was looking for a way to send him a feedb=
ack on his blog or somewhere else related to that proposal. The closest I f=
ound is this group.<o:p></o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:=
p></p></div><div><p class=3DMsoNormal>And you are right, that is what I am =
proposing. I think it keeps the original goal intact but adds a (imo useful=
) customization point.<o:p></o:p></p></div><div><p class=3DMsoNormal>There =
could be a std::throwing_allocator too, if that seems to be useful to many =
people.Or at least, given the idea of the&nbsp;<span style=3D'font-size:9.5=
pt;font-family:Courier;color:black'>polymorphic_allocator, </span><span sty=
le=3D'font-size:9.5pt;font-family:"Arial",sans-serif;color:black'>since C++=
17, a version of it that throws would be a good thing as well.</span><br><b=
r>On Thursday, October 18, 2018 at 9:15:45 PM UTC-6, Bryce Adelstein Lelbac=
h wrote:<o:p></o:p></p><blockquote style=3D'border:none;border-left:solid #=
CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>=
<div><div><p class=3DMsoNormal>It sounds like what you are suggesting is th=
at instead of making library functions that can throw unconditionally noexc=
ept, we:<o:p></o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div=
><div><p class=3DMsoNormal>* Make them conditionally noexcept if any user d=
efined allocators used can throw, and<o:p></o:p></p></div><div><p class=3DM=
soNormal>* Make std::allocator and operator new (aka the defaults) noexcept=
..<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div>=
<div><p class=3DMsoNormal>The result is the same in the default case; out o=
f memory is fatal. But if you use a customize allocator that can throw, you=
 get the current semantics.<o:p></o:p></p></div><div><p class=3DMsoNormal><=
o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>This sounds reasonable =
to me.<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><=
/div><div><p class=3DMsoNormal>Have you spoke to Herb?<o:p></o:p></p></div>=
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p><d=
iv><div><p class=3DMsoNormal>On Wed, Oct 17, 2018, 3:16 PM &lt;<a href=3D"m=
ailto:michel....@gmail.com">michel....@gmail.com</a>&gt; wrote:<o:p></o:p><=
/p></div><blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;p=
adding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=
=3DMsoNormal>In P0709, Herb Sutter proposes a zero-overhead deterministic v=
ariation of the exception mechanism by throwing a value of a size equivalen=
t to two pointers.<o:p></o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:p=
></p></div><div><p class=3DMsoNormal>I generally like the proposal a lot. I=
 am doing HPC programming and micro-controller programming and do see a lot=
 of benefit in squelching objections to the use of exceptions.<o:p></o:p></=
p></div><div><p class=3DMsoNormal>However, when it comes to the treatment o=
f heap exhaustion and, more importantly, the impact of it on the standard l=
ibrary, I am finding the proposal to be disturbing.<o:p></o:p></p></div><di=
v><p class=3DMsoNormal>In section 4.3.3 Herb proposes:<o:p></o:p></p></div>=
<blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><ul type=3Ddisc><li cla=
ss=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;=
mso-list:l0 level1 lfo1'>&nbsp;For each standard function for which allocat=
ion is the only reportable error, make the function noexcept. (We expect th=
is to result in making a large majority of functions in the standard librar=
y noexcept, including default and user-replaced ::operator new.)&nbsp;<o:p>=
</o:p></li></ul></blockquote><blockquote style=3D'border:none;border-left:s=
olid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right=
:0in'><ul type=3Ddisc><li class=3DMsoNormal style=3D'mso-margin-top-alt:aut=
o;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo2'>For code that wants t=
o handle heap allocation failures, provide explicit =E2=80=9Ctry to allocat=
e=E2=80=9D functions including the existing new(nothrow)<o:p></o:p></li></u=
l></blockquote><div><p class=3DMsoNormal>However this approach is disturbin=
g. It is essentially saying to go back to an equivalent of testing an error=
 code on return of every single call. Also because it goes against the idea=
s of writing a single generic routine for an algorithm because it seems to =
imply that every time I want to write an algorithm that involves a standard=
 library function that does a memory allocation, I should write both a regu=
lar version and a try_***&nbsp; version.&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal>So Herb wants that the vector&lt;T&gt; push_back should b=
e noexcept while the try_push_back can throw.<o:p></o:p></p></div><div><p c=
lass=3DMsoNormal>Though, I can see the use for having a try_*** in places, =
I wonder why he does not suggest to let the allocator used make the decisio=
n? Something like:<o:p></o:p></p></div><div><p class=3DMsoNormal>&gt;&nbsp;=
<span style=3D'font-size:9.0pt;color:green;background:#FAFFFA'>void push_ba=
ck (const value_type&amp; val) throws( can_throw_v&lt;Alloc&gt; ) ;</span><=
o:p></o:p></p></div><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><d=
iv><p class=3DMsoNormal><span style=3D'font-size:9.0pt;color:black;backgrou=
nd:#FAFFFA'>In my HPC work, I write library in which users can supply a mem=
ory buffer that my code can use. If I run out of memory, it is out of the q=
uestion that the code would crash. Instead it should be reported to the use=
r that she needs to provide a bigger buffer.&nbsp; I can do that by using a=
n allocator that throws an exception. Using a solution like I suggest above=
 would allow to still have noexcept if the user is fine with terminate bein=
g called and still allow to handle cases like mine gracefully in a way that=
 I can report to the caller as they are expecting. If the standard library =
always calls terminate on failure of allocation, then I'll have to resort t=
o not using the standard library, but using a&nbsp; modified clone of it. T=
his would be ironic,&nbsp; as one of the motivations of his proposal in the=
 first place is that people are not using the standard library.</span><o:p>=
</o:p></p></div></div><p class=3DMsoNormal>-- <br>You received this message=
 because you are subscribed to the Google Groups &quot;ISO C++ Standard - F=
uture Proposals&quot; group.<br>To unsubscribe from this group and stop rec=
eiving emails from it, send an email to <a href=3D"mailto:std-proposal...@i=
socpp.org">std-proposal...@isocpp.org</a>.<br>To post to this group, send e=
mail to <a href=3D"mailto:std-pr...@isocpp.org">std-pr...@isocpp.org</a>.<b=
r>To view this discussion on the web visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/cc411e93-53a3-4b24-8e02-68fda610c15=
e%40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank=
">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc411e93-53a=
3-4b24-8e02-68fda610c15e%40isocpp.org</a>.<o:p></o:p></p></blockquote></div=
></div></div></blockquote></div></div><p class=3DMsoNormal>-- <br>You recei=
ved this message because you are subscribed to the Google Groups &quot;ISO =
C++ Standard - Future Proposals&quot; group.<br>To unsubscribe from this gr=
oup and stop receiving emails from it, send an email to <a href=3D"mailto:s=
td-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubs=
cribe@isocpp.org</a>.<br>To post to this group, send email to <a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>.<br>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/b701aa54-f4b6-4d9a-8980-db398a=
a299e4%40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_=
blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b701aa5=
4-f4b6-4d9a-8980-db398aa299e4%40isocpp.org</a>.<o:p></o:p></p></blockquote>=
</div></div></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/008801d46808%24d33a08d0%2479ae1a70%24=
%40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/008801d46808%24d33a08d0%2479ae1a70%2=
4%40gmail.com</a>.<br />

------=_NextPart_000_0089_01D467CE.26E039E0--


.