220 40645 <70908db4-8cc7-41b2-b490-45119b8b5c5f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: michel.lesoinne@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0709 Heap exhaustion and try_... for standard library. Date: Fri, 19 Oct 2018 11:37:53 -0700 (PDT) Lines: 297 Approved: news@gmane.org Message-ID: <70908db4-8cc7-41b2-b490-45119b8b5c5f@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3688_1280911328.1539974273106" X-Trace: blaine.gmane.org 1539974150 29033 195.159.176.226 (19 Oct 2018 18:35:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 18:35:50 +0000 (UTC) Cc: michel.lesoinne@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZJZVFGWYHBBAWJVDPAKGQEC2Y3EJY@isocpp.org Fri Oct 19 20:35:45 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f197.google.com ([209.85.219.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDZcf-0007RH-ET for gclcip-std-proposals@m.gmane.org; Fri, 19 Oct 2018 20:35:45 +0200 Original-Received: by mail-yb1-f197.google.com with SMTP id w15-v6sf20109668ybm.15 for ; Fri, 19 Oct 2018 11:37:56 -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=tkYghv/pshGQldlfK7EBgMC6zQmbQOo2CYGocyy9NNc=; b=FTQVDnAaB8tvGISen1ZfVhVZ+BqEOOdf63c8LICXQZM5nJB2NX/JnB08eK1l7zbA2l Xqv8mOHEtZtgFPMbtxEjs7O7g1M1X0ZIfcHPVJFWiXKKNY4zPADcY8n0cXvhk4a3mKw4 pp7xWXWu7FI8I22+A23MYi+eXhScumwxztZZreJFGMOaKLCOauGgoiBJQzTvIGnk5VTg od+jUvIjo7Pb/oyjUWc+hsh4usSdle30BgYFwF5cArxUizQV4CQwtG+cSN5c+fAS6NW1 fwL4J8+NO8slTKfjoOiNFAMTf1tpYKyARs3UcIaXUAJmIcXu+jxZKAMR1Uhod8E4+97W PU1w== 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=tkYghv/pshGQldlfK7EBgMC6zQmbQOo2CYGocyy9NNc=; b=OMAt8PPCMUbtijslQCgCei+NHiZAwf/hyLyiVESn5rQKEI+byyo2JnrtHIUeQ8bfsK cgBZ9HXevZYdLRPqNyPcox37MeEQ4GOuIhtUGxOUBJ1tIoLFUl3L9gELSVHDQ4VicY0/ 5SiPmo8jLAwlrpNpsDociuQI0kguh8AWMAz+pdS0gmnalFGPVoCY35faG7MTaPs/8+2a 5BVOiz+GT+mMPRT7qxEwJR5D3/spFH5/90KXcbeYFm85uwua2j2GNL0RvrL8ImC+Nt7c J7kaMGS+ctURqmz/TPI+QyxPAGqfBAS9kuQw+ZS3MzTId1KSQK9Nb60dQe39PGGpTyt4 7Qng== 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=tkYghv/pshGQldlfK7EBgMC6zQmbQOo2CYGocyy9NNc=; b=SOoZLVCsGveY5QKAy4kRxaG0wKIzqjVGCmpTtl9+vugVMM4vtrnIwppg0AaWtdia+G 5AymO/E66M6HnGIUh5tQsBX7ccIkBFTpi9O7VSZyvsAdCP5CGftPjDTJ7UGKMWbNxh5Q V5Bneztm0Gag0tPgke0Fhf0SX5iMHFT9exz3VKim8OmU4bVBDwn+riaJ+CiatNChwM/e I1+CtZvcpq8S3TPHotewFPCS4bSCQCnDmHwGkvg3XMI4iJUmKCKMm8mHIYj50mpOT5gD y5K4L38feYDANCAAFMqoK5FMmTlC9mKUPMJoO1U94NvrnnN+fni3iGbFwzvN+//t6AkJ xyiQ== X-Gm-Message-State: ABuFfohb9eq7KsAF6YpggUxVH2OahvfXCIbo9PyPZFOueJGApm3sxLjo gTSpoRwNU/0AdkSNorEiIPe8UA== X-Google-Smtp-Source: ACcGV622gNRJZK5TttzBNiB88swUhiGIrenng6s14icLybgxK8GUNP/u7Ipk2HLh8/Pe6Zrbq9hhPw== X-Received: by 2002:a25:3d6:: with SMTP id 205-v6mr19275880ybd.84.1539974275789; Fri, 19 Oct 2018 11:37:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:ba08:: with SMTP id t8-v6ls10244793ybg.19.gmail; Fri, 19 Oct 2018 11:37:54 -0700 (PDT) X-Received: by 2002:a25:50cd:: with SMTP id e196-v6mr29624ybb.0.1539974273864; Fri, 19 Oct 2018 11:37:53 -0700 (PDT) In-Reply-To: X-Original-Sender: Michel.Lesoinne@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:40645 Archived-At: ------=_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 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 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 ) = ; >>>> >>>> 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 >>>> >>>> . >>>> >>> --=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
You are right. Wasn't sure it's the most appropria= te channel, but I will email him. Thanks.

On Friday, October 19, 20= 18 at 11:36:18 AM UTC-6, Ben Craig wrote:
"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."
Almost all papers include an email address that= can be used to provide feedback.=C2=A0 It's a paper "bug" wh= en there is no email address included.


On Thursday, Octob= er 18, 2018 at 11:18:25 PM UTC-5, michel....@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 somewhe= re 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 kee= ps the original goal intact but adds a (imo useful) customization point.
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=A0polymorphic_allocator= , since C++17, a version of it that throw= s 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 functions that can throw unco= nditionally noexcept, we:

* Ma= ke them conditionally noexcept if any user defined allocators used can thro= w, and
* Make std::allocator and operator new (aka t= he defaults) noexcept.

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

This sounds reasonable = to me.

Have you spoke to= Herb?


On Wed, Oct= 17, 2018, 3:16 PM <michel....@gmail.com> wr= ote:
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.
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 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.
In section 4.3.3 Herb proposes:
  • =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
  • 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/70908db4-8cc7-41b2-b490-45119b8b5c5f= %40isocpp.org.
------=_Part_3689_1626592930.1539974273106-- ------=_Part_3688_1280911328.1539974273106-- .