220 40596 article Path: news.gmane.org!.POSTED!not-for-mail From: michel.lesoinne@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: P0709 Heap exhaustion and try_... for standard library. Date: Wed, 17 Oct 2018 12:16:02 -0700 (PDT) Lines: 158 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2670_1860533616.1539803762753" X-Trace: blaine.gmane.org 1539803641 32354 195.159.176.226 (17 Oct 2018 19:14:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2018 19:14:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZJZVFGWYHBB5EUT3PAKGQEMNK74AA@isocpp.org Wed Oct 17 21:13:57 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f199.google.com ([209.85.219.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCrGW-0008JJ-V5 for gclcip-std-proposals@m.gmane.org; Wed, 17 Oct 2018 21:13:57 +0200 Original-Received: by mail-yb1-f199.google.com with SMTP id i192-v6sf15546434ybg.14 for ; Wed, 17 Oct 2018 12:16:07 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=plPTOv4O3DyEImRlgQvmI19cFY+XmPkQRzMDx2vJm4E=; b=zIj61iOrJHvfzc9povhO4VdJXvnZ3/yZ5Olv1025Xwvrcg6jBhJ+tzH1en8DedE8mN T5+nPG/QKhifb+x+jxxZLvRBd9vejpD1ut/32FGmFc26RzoT4ghzaXLmvHUXCorUmRVA 6/SSofASv3a51TzobSvmPJkksmsG841GUL2+SjyHKJhPt7dtyxEBsUuNxQZ4sDV8h/87 FjNlJ4XdBjEpWRdeJuwG66d2QM1MRj6OqsaRSimlyWAKTZxNSSi9GErj3tXouttBmyE2 WAjS9nsQ4RK0E0HttnmS9G2KpEm9qTNhixd4HdMYuFQZgzgpSBIPT6ZLGkUDYquDxhTf XQkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=plPTOv4O3DyEImRlgQvmI19cFY+XmPkQRzMDx2vJm4E=; b=X1qNqVIyasvGb8BkAesXDak9HvUjh6kv2J5/2runYpHbKxBf+QJmviCyu7uz9M77sY c1cKBGSjRMRN7a/+J+MwXjNd99xup34HfghvxdKVKzqwcHXYxEnKW98N6APIf8isrios iyDRhZbx1gIGuMsSfzSna+yjzUiUm7s850Edw2H2eZwM4OV6e+KPIhMXkVB+c2XK04aQ GEICWIyaIeMRCs+3uq0tGqGe84onkB8+HM8J3hPFZLecgbCD+saw/D+GqN0LT2PefePl CAtawOD1sMMIsnaTbnavtXQLXAJDHHjTZHyrJjJDhW2BSHS2J52jfiy5Yy/qcqmrCiW4 GsCg== 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: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=plPTOv4O3DyEImRlgQvmI19cFY+XmPkQRzMDx2vJm4E=; b=G8v1oMrDEjzp9QJlQceZA+wlR5RmnNO86T+eZsoBiudx1Zb+0oZbqS94b7z0Ve3kaM mypBTv5/g0dpUdJsmua3Zx+TsdsP5l5SA6bDOyYndwk1Fr5VOIUXRNe1MOmCdUgKXYhS a5unKePudVSuqjNHMx/tCSZRc0XiH/FU1TxbeYcohEmiPHcvzeV+1rNqQJ7w8Q1OZvY0 pc0G/0TfWAaYbSb9A5GKAR/fh6DgGdrr47Wpj3wssF66kzIdV11tgt6gs0JisAlr2g2d wZc/PMyTYARGe0s9ilf+7sbrRlkN8kmruF6KGE3V2U/BPJVAitlxIwcxMhf3ZHDAaE/u vBJg== X-Gm-Message-State: ABuFfoj+2J25AdBACr2WgFyuxbp9oza8JnlgiYzcFwblq8dTh7/m6y9R kZeEcr4iCbzrEj93WlbRrhG0KA== X-Google-Smtp-Source: ACcGV62mgf8hOrUQK98WVPI6hNtUpdLxBkk79h0L01BQAKZNxn6cco7ywcfwn4nu2tn6y8cu0Q7+gg== X-Received: by 2002:a81:3c06:: with SMTP id j6-v6mr16488182ywa.11.1539803765796; Wed, 17 Oct 2018 12:16:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:9b82:: with SMTP id v2-v6ls7970734ybo.6.gmail; Wed, 17 Oct 2018 12:16:04 -0700 (PDT) X-Received: by 2002:a25:1c83:: with SMTP id c125-v6mr351209ybc.6.1539803763579; Wed, 17 Oct 2018 12:16:03 -0700 (PDT) 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:40596 Archived-At: ------=_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 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 ) ; 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
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.

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.
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.
In section 4.3.3 Herb proposes:
  • =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
  • 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)
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=A0vo= id 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 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'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.=

--
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/cc411e93-53a3-4b24-8e02-68fda610c15e= %40isocpp.org.
------=_Part_2671_1939915150.1539803762753-- ------=_Part_2670_1860533616.1539803762753-- .