220 34258 <5044931.e35jvUQpKU@tjmaciei-mobl1> article Path: news.gmane.org!.POSTED!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to add constructors to std::bad_alloc exception class. Date: Fri, 01 Sep 2017 13:57:02 -0700 Lines: 201 Approved: news@gmane.org Message-ID: <5044931.e35jvUQpKU@tjmaciei-mobl1> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1504299444 20337 195.159.176.226 (1 Sep 2017 20:57:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 20:57:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBJ4TU7GQKGQEKDBSOEQ@isocpp.org Fri Sep 01 22:57:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnszy-0004Lc-2b for gclcip-std-proposals@m.gmane.org; Fri, 01 Sep 2017 22:57:06 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id q132sf206830lfe.2 for ; Fri, 01 Sep 2017 13:57:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1504299433; cv=pass; d=google.com; s=arc-20160816; b=KgfLG2IJv04K/xIvJeYb9Cz8NczmBbe9cbD97T0ghqqTKflUagCAhFOzn4jB9kSom5 5IXTxJUb+rmQtuhlxPLyEnj4ynDwgGz4iUCR2tEAf/0OjWJ1a1J7tF0x3oSLl7z8Q2ZS 204TZ3MWyMRvpVuV1rXzbfer1wudxwwMIdYXwmQ/2RIcQjsuhUxUTIYiZHiOqAOh5chh 6/OuviKmosP+BZo+cHlCGxeJ9corJtI4I7RKD5RT8Q2MASzDlTl7c9pBMu5lisNbkcFK uAp9Az5V5BaBnPhGs+MCMAYfx2H/+/E3kIh7hxREo3lCCXZo2rYwDBPT3i0KxrC1JLw7 2fUQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:to:from :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=cpxUHhDK0mRW3cKQwMrnvua2Y0C802qMTRvA2gTNdsA=; b=RS0epK7DTLa5QPBy0Tu6wXTFkwgd60rsfoB7Dxp1hpk0hhrT2ieOsqDVmL9EbUMvcG N0pO4b1b/wgINLkhPeOtPIYoUfNQFzXuySLOKGpaS3Lh3Sgzw71QfRGCzPrSKIe30QBf 9RLLPI+zr0uKromzxXdRqCSycBjE3C7iam/MGoOvLM/o5zwyDN8ljgfOrgUnk9wwO2fK J4dT+4969aXyvJ8xK11Jz6OxWTh6J65Hx1gy51m4NQL/SWG290HpI/T9qXXADvszHAEE lIeTDHDcX/5eXM1HrP/ndEcNIycaOytJ0kkNv6uIgoCspdqGkF7Ya/SYzUyC8n0KgaLc 75Jg== ARC-Authentication-Results: i=2; mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=cpxUHhDK0mRW3cKQwMrnvua2Y0C802qMTRvA2gTNdsA=; b=d2dmvSYWrZowPXcsrF3V63dv6m+b1cxfQJKWJbCmLjp7G+ENY2+az4ertZ/3ojjg2v BduT3yviXkkf1XVuNbFKS/hkdyuqTtyTEdbmVJEbUuF23MegFHNj3hGY45bQR9Kxukyb nh1RcAwKxUbBSMPU3xh3erek++4b0d9Uxj2fR40R2q0YlQ1MABeeeBQrHXgk+eInO7rw eAcjkUKF2lw3SQMWALp3/HqZN5WoNyI9UId5r7r58C8bb/vCAzifgO33yblzkDZ1KfwD IuHmExFKNa24AgxW5cVRxoPU/X3NX4Q+s5Wz8NCL4X9E0WdhpAaPDtgB4x/le57PqYWV 4RKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=cpxUHhDK0mRW3cKQwMrnvua2Y0C802qMTRvA2gTNdsA=; b=QTZ15n4qB+cfMY23f8Z7EcZK0L4315SWLhABl5oQ2OUDLtBkkvZMeLeEebm+Eg9mL0 TlYcfd6k1DhX3gy36zv9THfHOiG0spi/AP+WBgvaePxNiL7kZ5rZdEIhB8PqOAkTmpWc FwQGi5quH8L1j4aLzrk/JGVj206FV0q3a+kxPSdg/uoGsykeN0zkywSs198JSnkZmozb r2csWDIVIrCD57U0wGu//t9iPJZCb5Bq2Z4w59A6e5r35txLb+h3cBmbTYxtzOsH50u5 bfefV2ZQ7LDxuhe7P0pJmTjx/qFUagIyhA8Q3cUWUWd/XR1xLEWyGOKbz1gHO3JiI+uq yV1 X-Gm-Message-State: AHPjjUgTXSL9XARtwpQEUVx3VAFtB5JpKQsSXD/mTb0NreJvfJwEfb91 z004pTpqa91ZOIms X-Google-Smtp-Source: ADKCNb6DE/0JkUKEb5KH39uduH2CkWMjmDWrU9PW2srDBhVKfVbzMV4BzTH0R7xRGqHyW2MofI2uzg== X-Received: by 10.46.88.82 with SMTP id x18mr467855ljd.19.1504299433274; Fri, 01 Sep 2017 13:57:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.24.143 with SMTP id 137ls429427wmy.5.gmail; Fri, 01 Sep 2017 13:57:11 -0700 (PDT) X-Received: by 10.28.38.3 with SMTP id m3mr1107038wmm.4.1504299431528; Fri, 01 Sep 2017 13:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504299431; cv=none; d=google.com; s=arc-20160816; b=zcF9otjWlRk1Y18Id/noqFHV9mDr4iUm2Q0IV5z3ltGP9wZ7z+LmSAo59DQWjG6Goz CKspjxg9UQ8ttgoFS0ljdBK36g1lEF4zqwjSueB3PM2Wy+H52d/mQ3s8KDV57IYcVL4u WByNZOvI4sMYNXtupXfzE1z3ciej6ODp/l+WufpGYdNQuW0UOCqKi5drOOWMTJ/4hEdt +wpouexgIuNlV93wLyRyzAsKgKnHWVguqlIUtcBbguljG3wxhzhjWdIiwf736wgftBeE KtBJ3+gY9AFulCqZaboy+l3AIKX9qQJhypAGb79pF5EtiqeyffqAIjZXng5GZRNxcCxQ +xTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:arc-authentication-results; bh=oNfHkUpbjOW5E6Fe05g55EDrcTtRn+c3Zj3oQiq+1H4=; b=ZsGCsrJcq27cQZEEw5Axzu7/F7MDG7ZSFgIgDkZ2UBWHk5Oq79gcrY7vEXdjQOsRRO ifZpeO7Wn60D8VXsOhNx7OW9vaGAavlckGSLhDJE1jp4gkrH45FBo+z5/MGW2UElMb/K aMuZMzC0Spa93XJ7WoSJK6qBMORD0RE58TUKD4xtSOu0Eo4nKiZwmjyAnL52FxMxhYPC AMg/aUUNdEzTX3O4I43XmphMYR5C0x6ScxW/IjKzupEilBsxFSC6JAV5c13vvel/Au1k 6KZxsjEp0qVdvxlSyyNThhDMoZWLj/QdpsgGv3tDCFmL/HNVCzs3JxEB6oLaZXUTnvZ5 m4Cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id y10si692447wmh.267.2017.09.01.13.57.11 for ; Fri, 01 Sep 2017 13:57:11 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl1.localnet (unknown [134.134.139.76]) by gondolin.macieira.info (Postfix) with ESMTPSA id 694DA11B8D1 for ; Fri, 1 Sep 2017 13:57:10 -0700 (PDT) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org 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:34258 Archived-At: On Friday, 1 September 2017 12:28:44 PDT Rich Sposato wrote: > Hi, >=20 > I wrote this proposal after discovering the std::bad_alloc exception clas= s > only has a defaul= t > constructor. Other exception classes have constructors with a string > parameter. The lack of a similar constructor in bad_alloc has caused > problems for me. >=20 > This is the second draft of this proposal. Please provide feedback on how > to improve it before I submit it. This breaks binary compatibility by changing the size of bad_alloc. So ther= e=20 needs to be a VERY good reason for this to happen. So, what problems were those that you faced? What messages had you wanted t= o=20 include and couldn't? How would they be used? > The two additional constructors will accept either a reference to const > std::string or a pointer to a C-style string. These constructors will loo= k > identical to constructors in other exception classes. >=20 > explicit bad_alloc( const std::string & what_arg ); This constructor has problems. If the string outlives the unwound scopes, t= hen=20 you can call the constructor below. If it doesn't outlive, then it would me= an=20 bad_alloc would need to allocate memory in response to failing to allocate= =20 memory, which is nonsense. > explicit bad_alloc( const char * what_arg ); >=20 >=20 > An alternate constructor would use a string_view parameter instead of > either of the two above constructors. >=20 > explicit bad_alloc( std::string_view what_arg ); This could work and be used in replacement of the const char * above.=20 Fortunately, strlen can't throw or cause further problems. > *2. **Ease of making templates that construct exceptions.* > *3. **Ease of deriving subclasses from exception classes.* >=20 >=20 > Motivations #2 and #3 are related. They can be explained with a single > example that uses both templates and inheritance to show why bad_alloc > constructors should accept an explanatory string parameter. You need to explain why you're deriing from bad_alloc in the first place. > template < class ExceptionType > > class SmartException > { > public: > SmartException( const char * message, > unsigned int line, const char * function ) : >=20 > *ExceptionType( message ),* > line_( line ), > functionName_( function ) > {} >=20 > // ... rest of class ... > private: > unsigned int line_; > const char * functionName_; > }; >=20 > The SmartException constructor will call a subclass constructor that > accepts a string parameter. This works for most exceptions, but not > bad_alloc. Can't you specialise it as a member template with enable_if to take exactly= =20 the same arguments of the class that you're deriving from? > *4. **Changes to C++17 new and delete operators.* >=20 > There are several additional new and delete operators in the C++17 > standard. The additional operators all have a std::align_val_t parameter = to > support alignment-aware allocators. The std::align_val_t parameter will > become part of class-specific new and delete operators along with the > global operators. >=20 >=20 > void * operator new( std::size_t count, std::align_val_t al); >=20 > void * operator new[]( std::size_t count, std::align_val_t al); >=20 > void operator delete( void * ptr, std::size_t sz, std::align_val_t al ); >=20 > void operator delete[]( void * ptr, std::size_t sz, std::align_val_t al )= ; >=20 >=20 >=20 > Alignment-aware allocators would be unable to allocate the required numbe= r > of bytes if the alignment is incorrect. (e.g. =E2=80=93 The caller reques= ts > alignment on 16 byte boundaries, but the allocator only supports alignmen= t > on 4 or 8 byte boundaries.) If the allocator throws a bad_alloc exception > for the invalid alignment, the caller may assume the program is out of > memory instead of assuming the alignment is incorrect. Maybe it should throw something different, like bad_alignment_argument (we= =20 have bad_array_new_length). Though, to be honest, I wonder if it should thr= ow=20 at all or if it should just abort execution. This is not a runtime conditio= n,=20 this is a programming error. > Such a caller may > call a new_handler believing it will make more memory available. A > new_handler could spend an enormous amount of time looking for memory tha= t > is available only to find none, simply throw another bad_alloc exception, > or terminate the program by calling std::abort or std::exit. None of thes= e > actions will resolve the simple problem of using the correct alignment. Agreed. That leads to the conclusion that throwing std::bad_alloc or callin= g=20 new_handler in response to wrong alignment values is the wrong action to ta= ke. > This means that a bad_alloc exception with a valid explanatory string cou= ld > provide the caller with actionable information to solve the problem, whil= e > a bad_alloc exception with no (or an inaccurate) explanatory string would > lead the caller to perform an expensive or program-ending action. The string is the worst way to report this problem. Why would an exception= =20 handler do a strcmp on what()? In fact, *what* would it strcmp to? If you'r= e=20 going to distinguish, do it on the typeid, which is what catch() does. > *5. **Allowing allocators to inform callers exactly why allocations > failed.* >=20 >=20 > Allocations may fail for reasons other than the program ran out memory. > There are specialized allocators that only handle requests for specific > sizes, such as pool allocators, that could throw exceptions if they recei= ve > requests for sizes they cannot handle. Same as alignment issue: the type of the thrown exception should be differe= nt. > 1. Should the bad_alloc exception be used only allocators fail from > lack of memory? IMHO, yes. > 2. Can it also be used for allocations that fail because of invalid > parameters (e.g. wrong size or alignment)? No. > 3. Can it also be used for allocations that fail because of internal > problems with the allocator? No. > However, many programmers 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. And well they shouldn't. As I said, those errors indicate programming error= s,=20 not runtime conditions that can be handled. --=20 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center --=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/5044931.e35jvUQpKU%40tjmaciei-mobl1. .