220 40644 article Path: news.gmane.org!.POSTED!not-for-mail From: Ben Craig Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0709 Heap exhaustion and try_... for standard library. Date: Fri, 19 Oct 2018 10:36:18 -0700 (PDT) Lines: 285 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3603_1004434621.1539970578245" X-Trace: blaine.gmane.org 1539970455 21370 195.159.176.226 (19 Oct 2018 17:34:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 17:34:15 +0000 (UTC) Cc: michel.lesoinne@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDCM7T7A5UMRBE5MVDPAKGQENRRI2FA@isocpp.org Fri Oct 19 19:34:11 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDYf4-0005Ps-Rd for gclcip-std-proposals@m.gmane.org; Fri, 19 Oct 2018 19:34:11 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id n143-v6sf22020332ywd.6 for ; Fri, 19 Oct 2018 10:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=D/4XsDfw5FBYd9TC0fER+18sNlL4Qq4x4vcRGTWYvtM=; b=eDZnxa22vVeMqWLfpRJUEHSvgjtBe9i0lycIh8pLJ0H59n0lmscdIGeDeKqRYjBwR7 OTLpCSd2IMHBEKvXgI2UD8LPl6VJOBfkhFQLmOvM1CnggDa30AVPmTonw5J6P2b7Q0lY sPNDN/sBToJABme0E08XjloXZNrC/DUNHYa9NkMztuVWIJlcmMOfxfTG13PDTK/6E8Mh MHfOpXJ0mKD3py7oY9FnZoXP7ZOVricVazXUtAFwu0ePjK1QPWGzXoRbT2DgnCcF1Xm5 TmINa+eDwuWwCfGdA0Sb2Q8hctlO27ppiNv6aLIPINGveAu3JeUwNHGoIsCFqa4DhpJo 7Kkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=D/4XsDfw5FBYd9TC0fER+18sNlL4Qq4x4vcRGTWYvtM=; b=XH33SAVRBrmUdtoqNK2g3DtHozioobFuFuUerqVlSsaFKN3Ik+a4JfyxEuNgSAibRc 2ljU5wGftgJHC9u8rks3abXorkSRQTScNQlgdAfuDuwedUeoTrmvqxeNiPePWZ+YrLLO S9/aFA8HJ/XlEKqv/R6prZOeICVShmD4KKoysbOXy3Rx0UtwY2B3W+p3NDSNz3nzaZvV K43N6sYc7yP+DKqmBV5gAST4xviq9jSh/gomBzc80xbEyCBWqiOv3bi9ZOWaFYA7KCjk 8Q/bKfx+HXkBdp/DouWsAvHOcvK3Ch7YwglgPBPcIUunp1OSSmx2/l0MbBkY/QMXAyUv nVRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=D/4XsDfw5FBYd9TC0fER+18sNlL4Qq4x4vcRGTWYvtM=; b=kpMRzZNOknH8ll3FYFC7iuzdoWWUeg9OCvc5nsQgfMR7ai+nvxAIDhfzxLtdfLIqJP UTS4BVH41fG029DqD0pBcZmAMENQgBZHlkuaiSjdUFYFeEcIxQ3iW+3BBYQi8xIT96rE 6uodkk+HzcT8glubyA3PnPaMCbrb1tN+OcqQABaMiVhVtA/oWKqlIogA4X844wMIQpMU xAdu54OAK4UTViIn1XzVxQ54d0Bxn+vBdtoe7KgBhYuTVXoMfuUSpUs+In5uRFzSjjeq VDXA/1b8I/K+ERtN+re74FPRjoggZPMIui0wk6pWBXjkcebIJoOZVNoMxgGmaDpC21pW FUxA== X-Gm-Message-State: ABuFfoicKNdAakC0eZzu/zRdDpZ2bCstdG67nNT+iMyg7UqWEG8gcC3e qHBGS/Blja1onFs3BR3E5PpzDA== X-Google-Smtp-Source: ACcGV60JK/zJjKdBQL3L9b5SZmnJ9okZ9zTx81IOx67N2R8Wrwf8HceAHpK/6w9I2FvzePL25n0WeA== X-Received: by 2002:a25:9d06:: with SMTP id i6-v6mr19427349ybp.4.1539970580565; Fri, 19 Oct 2018 10:36:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:6dc3:: with SMTP id i186-v6ls7806154ybc.10.gmail; Fri, 19 Oct 2018 10:36:19 -0700 (PDT) X-Received: by 2002:a25:1c83:: with SMTP id c125-v6mr444151ybc.6.1539970578893; Fri, 19 Oct 2018 10:36:18 -0700 (PDT) In-Reply-To: X-Original-Sender: ben.craig@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40644 Archived-At: ------=_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 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 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 ) ; >>> >>> 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 >>> >>> . >>> >> --=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
"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."
Almost all papers include an email address that can be use= d to provide feedback.=C2=A0 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 wrote:
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.

= 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=C2=A0polymorphic_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 Lelbach wrote:
It sounds like what you are suggesting i= s that instead of making library functions that can throw unconditionally n= oexcept, we:

* Make them condi= tionally noexcept if any user defined allocators used can throw, and
<= div dir=3D"auto">* 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 cust= omize allocator that can throw, you get the current semantics.

This sounds reasonable to me.
<= div dir=3D"auto">
Have you spoke to Herb?
<= br>
On Wed, Oct 17, 2018, 3:= 16 PM <michel....@gmail.com> wrote:
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.

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.
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:
=
  • =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
  • 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)
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
So Her= b 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 m= ake the decision? Something like:
>=C2=A0void push_ba= ck (const value_type& val) throws( can_throw_v<Alloc> ) ;<= /div>

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'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.

--
You received this message because you are subscribed to the Google Groups &= quot;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.
To post to this group, send email to std-pr...@isocpp.o= rg.
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.org.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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.org.
------=_Part_3604_2043015965.1539970578246-- ------=_Part_3603_1004434621.1539970578245-- .