220 34263 article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to add constructors to std::bad_alloc exception class. Date: Fri, 1 Sep 2017 15:49:44 -0700 (PDT) Lines: 217 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_3136_1568527647.1504306184462" X-Trace: blaine.gmane.org 1504306204 20413 195.159.176.226 (1 Sep 2017 22:50:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 22:50:04 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIITSFHZUCRUBFY36KCO@isocpp.org Sat Sep 02 00:49:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnuku-00041n-21 for gclcip-std-proposals@m.gmane.org; Sat, 02 Sep 2017 00:49:40 +0200 Original-Received: by mail-pf0-f199.google.com with SMTP id w89sf3007261pfk.9 for ; Fri, 01 Sep 2017 15:49:47 -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=/rFrkul+MEz9wXdNaGv9vnYW6RbbfVXfsGNyqTeqarQ=; b=sc5te8Tbkjmdxv91yAYgqEt5IMzXQEA1Bx/CsX2q7DqN6BbhS/bg2Pd99Ae5CIorCh 1RX0lqvrzPyNWLSYMlVyvIPNGuTl+onZfpNWW2n0+2DVyx455780pFJ8EMrxcnpw+cyh TEinIrz3O9h9A9Kuls/D9/tOjF8uVPTZTGmmK6vyRqi9C4zlbKDdeDw6LwcLzBOQTGHF Ivx7dEE1yoFsC4ImdnCGC87V8hK2wuJ3vN9XtxjNSLGBRQtUfjzJ7cb1OIOY/6KMnP2R SrwThu/zjr3V1VGVcKiO1OqjiBubKc5TN/LlgBYfww8J0ILpK+OBXHEEPEHsIx6/s6fv 2UCg== 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=/rFrkul+MEz9wXdNaGv9vnYW6RbbfVXfsGNyqTeqarQ=; b=L/0Ka+Lj+bhh3Jf5td8DcHxB2hdlz0wc28L72hzlSAoSybVMne4CS7QmjUMQU8IZVx dz2xmGEt0TPi1mg3YyvpOTiO2B6Zchkd373GHsMhzRSTzyCBo0g2lNEErVo4FioTIpxa /uwSyRz7+b+DUcQHPjvp19dMbeUPXzV8td63yH784hQcyOAzGQF1fF7gdLVvkpHXnHmW 8NDhtE/6rANSth5cdqiovC9HtWoHCwN8wiv+BmGbeRZnlMz1p8dL9PpLcm/v8X+9zDjz q3X4b+5VOM9665HN9l9GyVHSTevgBl8igVZDyjkl4mxHH50gmhP7hjYKsmRwZcgabxfL 1vCA== 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=/rFrkul+MEz9wXdNaGv9vnYW6RbbfVXfsGNyqTeqarQ=; b=N0wEtr2l7/cByDsSdOgMIWuIGTmqZANo0mjpUR4FwzA3hHpg+MXyQazpVi+xwxS5DG WmATQuz4iU8NwKdCIQ60I7Ibx71DBuaCHuf4zefuabZfEm6ihVkciYfD2CkNo/KsDmfr OZhTC8W3CtPf1uQvMs9aFSbUk1993fgT/7I6sI48lpiZsF3cv7AcgHjM1C5ocOHfXvXQ BeWDhodZ4TeecexvYK8W90hvYP6+cEDCw/JiIeZnEg+u8KpOOSHJ3ZG4xSnthx46uPsr sQvy5X19lpPCHCMntMGtpHsjqFKb19CwZC1uge+C0ba+9ef/J5rMrJ+9XCnALdYepjAT wmOg== X-Gm-Message-State: AHYfb5hDY2C4SETdtX7YPUjWvWsgS3wXdsK8IamNpvypdBBfpIdjrRGK Vg7bUcQyHhDvmCr+ X-Google-Smtp-Source: ADKCNb7fnzIvC+DeT1riJafwORqfADcr05/oOAY/Xm16871cfw/EfQWqJKW8wuG/gcvBL7llCEaaHQ== X-Received: by 10.98.33.89 with SMTP id h86mr4461964pfh.22.1504306186322; Fri, 01 Sep 2017 15:49:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.54.209 with SMTP id l200ls1693488itl.13.gmail; Fri, 01 Sep 2017 15:49:44 -0700 (PDT) X-Received: by 10.31.199.65 with SMTP id x62mr93912vkf.9.1504306184906; Fri, 01 Sep 2017 15:49:44 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:34263 Archived-At: ------=_Part_3136_1568527647.1504306184462 Content-Type: multipart/alternative; boundary="----=_Part_3137_967671686.1504306184462" ------=_Part_3137_967671686.1504306184462 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, September 1, 2017 at 12:28:44 PM UTC-7, Rich Sposato wrote: > > Hi, > > I wrote this proposal after discovering the std::bad_alloc exception clas= s=20 > only has a=20 > default constructor. Other exception classes have constructors with a=20 > string parameter. The lack of a similar constructor in bad_alloc has caus= ed=20 > problems for me. > If you're going to claim that it "caused problems", you should mention some= =20 of those problems, so that people can suggest alternative fixes. My initial very strong impression is that you have an XY problem. If you want to throw something that catches-like std::bad_alloc but also=20 includes some additional member data... well, that's what inheritance is=20 for. class SmartBadAllocException : public std::bad_alloc { std::string what_; public: SmartBadAllocException(const char *what) : what_(what) {} const char *what() const override { return what_.c_str(); } }; Does this solve the problem you had? 1. Should the bad_alloc exception be used only allocators fail from=20 > lack of memory? > > 2. Can it also be used for allocations that fail because of invalid= =20 > parameters (e.g. wrong size or alignment)? > > 3. Can it also be used for allocations that fail because of internal= =20 > problems with the allocator? > 1. No, because (2). 2. Yes. I do this, for the reasons you stated below. 3. Yes, but "internal problems" suggests that an invariant failed, so I'd= =20 rather throw AssertionFailure or just go undefined-behavior. Throwing=20 bad_alloc when an invariant has failed is probably going to hide the=20 problem, whereas the debugging human would really rather see it flagged=20 loudly. One answer to the first and second questions is that allocators should=20 > throw an out_of_range or invalid_argument exception when the size or=20 > alignment parameter is invalid. Likewise, one could say allocators should= =20 > throw logic_error or runtime_error for internal problems. These answers= =20 > imply bad_alloc is reserved strictly for out of memory conditions, but no= t=20 > for other conditions that arise during allocations. > > > However, many programmers write code assuming that allocators only throw= =20 > bad_alloc. They do not expect to catch logic_error or invalid_argument=20 > exceptions, so these exceptions will propagate past the functions that=20 > should have caught them. For that reason, I recommend using bad_alloc for= =20 > any problems that arise during allocations. > I agree. Pet peeve: The C++17 allocators such as std::pmr::monotonic_buffer_resource= =20 do not throw anything on invalid/too-aligned alignment; instead, they=20 quietly return less-aligned pointers. If you're using one of these=20 allocators, you'd better be checking every allocation to make sure the=20 allocator didn't quietly give you a misaligned pointer! :P =E2=80=93Arthur > --=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/d5996110-3605-4a34-a660-223f38f980c8%40isocpp.or= g. ------=_Part_3137_967671686.1504306184462 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, September 1, 2017 at 12:28:44 PM UTC-7, Rich Sp= osato wrote:
H= i,

I wrote this proposal after discovering the std::ba= d_alloc exception class only has a default constructor. Other exception= classes have constructors with a string parameter. The lack of a similar c= onstructor in bad_alloc has caused problems for me.
<= div>
If you're going to claim that it "caused proble= ms", you should mention some of those problems, so that people can sug= gest alternative fixes.
My initial very strong impression is that= you have an XY problem.

If you want to throw some= thing that catches-like std::bad_alloc but also includes some additional me= mber data... well, that's what inheritance is for.

=
class SmartBadAllocException : public std::bad_alloc {
=C2= =A0 =C2=A0 std::string what_;
public:
=C2=A0 =C2=A0 Sma= rtBadAllocException(const char *what) : what_(what) {}
=C2=A0 =C2= =A0 const char *what() const override { return what_.c_str(); }
}= ;

Does this solve the problem you had?
<= br>

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should the bad_alloc exception be used only allocators fail from lack of memory?

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Can it also be used for allocations that fail because of invalid parameters (e.g. wrong size or alignment)?

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Can it also be used for allocations that fail because of internal problems with the allocator?

=

1. No, because (2).
2. Yes. I do= this, for the reasons you stated below.
3. Yes, but "intern= al problems" suggests that an invariant failed, so I'd rather thro= w AssertionFailure or just go undefined-behavior. Throwing bad_alloc when a= n invariant has failed is probably going to hide the problem, whereas the d= ebugging human would really rather see it flagged loudly.

One answer to the first and second questions is that allocators should throw an out_of_range or invalid_argume= nt exception when the size or alignment parameter is invalid. Likewise, one could say allocators should throw logic_error or runtime_error for internal problems. These answers imply bad_alloc is reserved strictly for out of memory conditions, but not for other conditions that arise during allocations.


However, many progr= ammers write code assuming that allocators only throw bad_alloc. They do not expect to catch = logic_error or invalid_argument exceptions, so these exceptions will propagate past the functions that should have caught them. For that reason, I recommend using bad_alloc for any problems that arise during allocations.

<= /blockquote>

I agree.

Pet peeve= : The C++17 allocators such as std::pmr::monotonic_buffer_resource do not t= hrow anything on invalid/too-aligned alignment; instead, they quietly retur= n less-aligned pointers. If you're using one of these allocators, you&#= 39;d better be checking every allocation to make sure the allocator didn= 9;t quietly give you a misaligned pointer! :P

=E2= =80=93Arthur

--
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/d5996110-3605-4a34-a660-223f38f980c8= %40isocpp.org.
------=_Part_3137_967671686.1504306184462-- ------=_Part_3136_1568527647.1504306184462-- .