220 40620 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: Thu, 18 Oct 2018 21:18:25 -0700 (PDT) Lines: 278 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_3351_221187282.1539922705763" X-Trace: blaine.gmane.org 1539922582 26226 195.159.176.226 (19 Oct 2018 04:16:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 04:16:22 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZJZVFGWYHBBEVWUXPAKGQEXNVPHYI@isocpp.org Fri Oct 19 06:16:18 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f198.google.com ([209.85.219.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDMCv-0006jN-U8 for gclcip-std-proposals@m.gmane.org; Fri, 19 Oct 2018 06:16:18 +0200 Original-Received: by mail-yb1-f198.google.com with SMTP id c8-v6sf450664ybs.2 for ; Thu, 18 Oct 2018 21:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=5E4sEVRUfj0vPFxF7ADfEagCKFJcvF3Ob7XZbaIDtVc=; b=aKA4JX7KH1BbqNGWP0WZ8WAHK0LsBA4CovJn1o15zk2iO2qr4jWAg6Lxc+t5fh60Yt nmuUr4PZGCMNSxTRv8NweL2PWMmESEQ1WSvndyGZWgLQrzKgr3ifHPUEFwFxjXRZGEM7 XaLU8j23xckb0yDjVeEd+YkLgEku0mjt01Hk35IxcdwIBt96WBgwQTrIlJkwh1KFs8Y5 B91lJCP7mpgHuGM00gr8XmRXzy2mL3uUA/ZcNJ1KeORmiUNFbC2qoTdItD5Xj0pygbMy /8dTWOeCDZkl+Bpj/CJN+TrnwrHj2MLtvuHKUB+4ezWO69ZcKsRASQqu5CDk2Qsb6eCZ uiow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=5E4sEVRUfj0vPFxF7ADfEagCKFJcvF3Ob7XZbaIDtVc=; b=TmT0ttcKbLy8EVheg9KTgZiyUuL3GL1tU1FYn59ZXGtwEls1JklYNmw8rjIv0mZbRk Y9pSvg98YFI1t4eygqjdBmztbbZVZ+CEqasTPYL32ycZkjrmPetChMS8Cvet1Ba46NCZ OobdXo/KAY+M4m7lyJkXf7MsgEf8uKDmcp7sE5/Byhhs9tiW04MH96PZgV0SWCVLaLvB b0suiHuBAuMSCp3w/Z7RSQOjICi/2d6Lqua4EjwrcFHpsSUYOaBwCrtUREfRc350DnBI j9QZKhdonyo73pUqvKEraDbLYUwlWqB/B6H7GmfUnRg+nvy1NVtl+KSNap5mvRGAXkmV US3Q== 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: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=5E4sEVRUfj0vPFxF7ADfEagCKFJcvF3Ob7XZbaIDtVc=; b=Y2DJ5QwdsFCAYOUDZZPm8Kr5HNQMh0/LaL+sA4QFd+vHM1ZIJxvvmDNAclJv56eBMh jdNaGo9QcnmEyZJ6+yF+A1GKDlxvgbPHEyO4pdIjpUJI3saRz8DgRviDDW+sHjhNFmLa cK+6yVCx1oM/Vu5kwUi7jNnXYYlybEq/CqRqAsnOvZ4B4ldl8DP0YzbYZngGx8YlV8ZH ESTm7pKS2m87hHqQyb31Ygx5iF71quCeoKRRl8BZxewEDBf9FcekrIB5rrUGD8HuC4Sx 7TFatxeKm3adldc+inK64ufcIkT1OGuPOyAbg/3tcQbwmwzIgyH1vAahEYSb2g2MQzRw Ed1g== X-Gm-Message-State: ABuFfoi3+PqdWcv1h5OVNgQocArvSs6yE0BxpmH9Ppy/CMYhB3cY4U8x iNDLOly5BqbKpIc6IRUVjyZe+Q== X-Google-Smtp-Source: ACcGV62dndiRLJsclgDvnEVkA3mbE0nFvhBVHfG0SvwjrY7JlodEj5cwdgBpNJBbK3XU10z9JW6RhA== X-Received: by 2002:a5b:a83:: with SMTP id h3-v6mr2602377ybq.60.1539922708114; Thu, 18 Oct 2018 21:18:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:6dc3:: with SMTP id i186-v6ls7157678ybc.10.gmail; Thu, 18 Oct 2018 21:18:26 -0700 (PDT) X-Received: by 2002:a25:d90a:: with SMTP id q10-v6mr411450ybg.0.1539922706212; Thu, 18 Oct 2018 21:18:26 -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:40620 Archived-At: ------=_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 > 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 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 ) ; >> >> 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 . >> 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-53= a3-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/b701aa54-f4b6-4d9a-8980-db398aa299e4%40isocpp.or= g. ------=_Part_3352_1889269543.1539922705764 Content-Type: text/html; 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 feedback on his blog or somewhere else related to that proposal.= The closest I found is this group.

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.
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=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 sugges= ting is that instead of making library functions that can throw uncondition= ally noexcept, we:

* Make them= conditionally noexcept if any user defined allocators used can throw, and<= /div>
* Make std::allocator and operator new (aka the defa= ults) noexcept.

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 dir=3D"auto">
This sounds reasonable to me.<= /div>

Have you spoke to Herb?<= /div>

On Wed, Oct 17, 20= 18, 3:16 PM <michel....@gmail.com> wrote:
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.

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.
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.
In section 4.3.3 Herb proposes= :
  • =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
  • 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.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.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/b701aa54-f4b6-4d9a-8980-db398aa299e4= %40isocpp.org.
------=_Part_3352_1889269543.1539922705764-- ------=_Part_3351_221187282.1539922705763-- .