220 34254 article Path: news.gmane.org!.POSTED!not-for-mail From: Rich Sposato Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Proposal to add constructors to std::bad_alloc exception class. Date: Fri, 1 Sep 2017 12:28:44 -0700 (PDT) Lines: 3057 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_2952_496205681.1504294124648" X-Trace: blaine.gmane.org 1504294141 32430 195.159.176.226 (1 Sep 2017 19:29:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 19:29:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNJHDWPTQMBB3PJU3GQKGQENU7X46I@isocpp.org Fri Sep 01 21:28:50 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnrcP-0007Rl-1X for gclcip-std-proposals@m.gmane.org; Fri, 01 Sep 2017 21:28:41 +0200 Original-Received: by mail-it0-f69.google.com with SMTP id b76sf526161itb.6 for ; Fri, 01 Sep 2017 12:28:48 -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=3TH47Vnkt7uBIoB8tb/jbRFuZ1+CAPBwg88NBvnvq0Y=; b=ew2VauTDFU4H5R5HCoMJ7gCC2JuIQ9nC7ZnFBz7uK/dZbu89I78IQEGcF3yBCWvdFj ZM9nTi34VbWPrsXnz6IgD3hJ5+BjgFiK09cwWfPaTtYgV3eBQo/UfMzCuXUj+UA2RdfZ TA3dPVRqhwz5NF3wukxFvr9HwO4CNwkUMoPbaYuuCHN9R9BT1+yM21J+ZEN3RGCExYJk j5lQJ8aj/tYmezN15tj1L0les9o0wKwaNTxHyDJWmqI4b/58o6hEK46xqfG/1Oc1edVH OuFY6Lv1EVHmCOZFJuM0cwkXJMVbsYKqi3gT5fxeVeiJCwCp116bDlbIHv/7LkpdCrRt Z1zA== 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=3TH47Vnkt7uBIoB8tb/jbRFuZ1+CAPBwg88NBvnvq0Y=; b=PCngT39zRf+aywt/3Or6PxBQ+VufG8JDegt9R4jzqMI9TSzinRFtWe0kI/bv1PAJBN OIdQZCNYhw+OtNADbg9NvbCzOzfuY0lCwYA+613fEeVdx6v6uXBJPczgUZdKHRtfjwnf cJjVmIeCbFPInaCTxEAwa7QL9vWPZ/sNnHWwaIQhSQJWrJIDkjtD+eSE8r9Z2Jpgh2xD uH/WtrhaPOBy7yhYu5ntaf66W71NHUDyl8YDSG2DFVT+Glr1d7Y6+LTNrFFepmLTUger VfffcsHcueQsVT1NDpW/2Y82pHs4hNuH6LOQ0pO69vBdhGCBGv7UfhF3nmQz9xwV3qhE sqhA== 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=3TH47Vnkt7uBIoB8tb/jbRFuZ1+CAPBwg88NBvnvq0Y=; b=WXAZDVA+2p3NPbXAWGLy3PcbU6MUJPIsuXH4ndkQ23FiP+C0LCOsexOmgrMMF1Yfrm wDVtnIVaXa+cu4dmhXFh2TRRId8guq+y0kVLuWzzMBwqS0cC2VgAfPF/2Uu5xyChfKPH f7PO9YxhUnp0yGG2fpFm7c5LKqJ0S6CkGWVA6eYiewaiT38AVRhdxNLiISzcOC9Ld1vH cexu1G23aB8hGCeMm6hm1akMcR7jrQZcGn2Da6AiCLVvDNY7aoIoNOEW/vTnKRzfp3GC vQ+vuajGygSsY6ME8OyDLnEc3CzeNRVNBwNjBT0XelPoXUMKYBzadgNPDI9+DVY/kIaE ZfBg== X-Gm-Message-State: AHPjjUg/QZpSAo4Y1tJIPHYC883vbEKQ3AaKy+X5sbVrukX7rom2jkwu NOuqeffH5t+J+cn9 X-Google-Smtp-Source: ADKCNb7tAbsdtXRuMEhOHF0XkW0aM0EaIRKVvWQgCZVG/Vv0PVufs1mYlTJXESbbo7Vxh2rgLIbnBA== X-Received: by 10.107.151.193 with SMTP id z184mr5683771iod.79.1504294127287; Fri, 01 Sep 2017 12:28:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.79.76 with SMTP id c73ls1530001itb.10.canary-gmail; Fri, 01 Sep 2017 12:28:45 -0700 (PDT) X-Received: by 10.31.146.11 with SMTP id u11mr83232vkd.22.1504294125248; Fri, 01 Sep 2017 12:28:45 -0700 (PDT) X-Original-Sender: rich.sposato@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:34254 Archived-At: ------=_Part_2952_496205681.1504294124648 Content-Type: multipart/alternative; boundary="----=_Part_2953_1219705336.1504294124651" ------=_Part_2953_1219705336.1504294124651 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I wrote this proposal after discovering the std::bad_alloc exception class= =20 only has a default= =20 constructor. Other exception classes have constructors with a string=20 parameter. The lack of a similar constructor in bad_alloc has caused=20 problems for me. This is the second draft of this proposal. Please provide feedback on how= =20 to improve it before I submit it. I would especially prefer feedback on wording and style so that it conforms= =20 with the wording and style of accepted proposals. I would also like=20 feedback on technical correctness. If anybody has insights on upcoming changes to the standard exception=20 classes that might affect this proposal, please let me know. If you prefer a Word document version of this proposal, please let me know. Thanks, Rich Sposato =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The bad_alloc Constructor Parameter Proposal =20 By Richard Sposato September 2017 Contents I. Introduction. 1 <#_Toc492030627> II. Technical Specifications. 1 <#_Toc492030628> III. Motivation. 2 <#_Toc492030629> IV. Impact on the Standard. 5 <#_Toc492030630> V. Design Decisions. 5 <#_Toc492030631> VI. Acknowledgements. 5 <#_Toc492030632> VII. References. 5 <#_Toc492030633> =20 =20 I. Introduction=20 A proposal to add two constructors to the std::bad_alloc class so it=20 conforms to other exception classes. *Intended Audience:* These changes are intended for C++ programmers of intermediate through=20 expert skill level who are either authors or users of memory allocation=20 libraries. =20 II. Technical Specifications=20 The current implementation of bad_alloc class supports only the default=20 constructor. To avoid breaking existing code, this constructor will=20 continue to exist, and will provide an implementation defined explanatory= =20 string for the what() function. bad_alloc(); The two additional constructors will accept either a reference to const=20 std::string or a pointer to a C-style string. These constructors will look= =20 identical to constructors in other exception classes. explicit bad_alloc( const std::string & what_arg ); explicit bad_alloc( const char * what_arg ); An alternate constructor would use a string_view parameter instead of=20 either of the two above constructors. explicit bad_alloc( std::string_view what_arg ); =20 Each will construct a bad_alloc exception object that stores what_arg as an= =20 explanatory string that can be accessed through the what() function. =20 III. Motivation=20 There are several motivations for this proposal. Each of these will be=20 described in detail. 1. Conformance to existing exception classes. 2. Ease of making templates that construct exceptions. 3. Ease of deriving subclasses from exception classes. 4. Changes to C++17 new and delete operators. 5. Allowing allocators to inform callers exactly why allocations=20 failed. =20 *1. **Conformance to existing exception classes.* All other exception classes in the std namespace provide constructors that= =20 accept either a single parameter of either a reference to a const=20 std::string or a pointer to a C-style string. The parameter provides a=20 human-readable explanation for why the program threw an exception or=20 actionable information allowing the calling code to correct the problem. =C2=B7 logic_error =C2=B7 invalid_argument =C2=B7 domain_error =C2=B7 length_error =C2=B7 out_of_range =C2=B7 runtime_error =C2=B7 range_error =C2=B7 overflow_error =C2=B7 underflow_error =C2=B7 tx_exception Conformance to other exception classes will enable motivations two and=20 three for this proposal. =20 *2. **Ease of making templates that construct exceptions.* *3. **Ease of deriving subclasses from exception classes.* Motivations #2 and #3 are related. They can be explained with a single=20 example that uses both templates and inheritance to show why bad_alloc=20 constructors should accept an explanatory string parameter. Classes that derive from the standard exceptions cannot call the bad_alloc= =20 constructor using the same code they would to call other exception classes.= =20 This example illustrates how to wrap existing exception classes with a=20 smart-exception class that derives from standard exceptions. template < class ExceptionType > class SmartException { public: SmartException( const char * message, unsigned int line, const char * function ) : *ExceptionType( message ),* line_( line ), functionName_( function ) {} // ... rest of class ... private: unsigned int line_; const char * functionName_; }; The SmartException constructor will call a subclass constructor that=20 accepts a string parameter. This works for most exceptions, but not=20 bad_alloc. These lines define various smart exceptions using the above class and=20 typedefs. typedef SmartException< std::bad_alloc > SmartBadAllocException; typedef SmartException< std::logic_error > SmartLogicErrorException; This function shows how code would throw a smart exception so any code=20 catching the exception can report exactly where the problem occurred. void * Allocator::Allocate( std::size_t bytes, std::size_t alignment ) { void * place =3D FindPlace( bytes, alignment ); if ( place =3D=3D nullptr ) { *throw SmartBadAllocException( =E2=80=9CError! Unable to alloca= te=20 bytes.=E2=80=9D,* * __LINE__, __FUNCTION__ );* } return place; } =20 *4. **Changes to C++17 new and delete operators.* There are several additional new and delete operators in the C++17=20 standard. The additional operators all have a std::align_val_t parameter to= =20 support alignment-aware allocators. The std::align_val_t parameter will=20 become part of class-specific new and delete operators along with the=20 global operators. void * operator new( std::size_t count, std::align_val_t al); void * operator new[]( std::size_t count, std::align_val_t al); void operator delete( void * ptr, std::size_t sz, std::align_val_t al ); void operator delete[]( void * ptr, std::size_t sz, std::align_val_t al ); =20 Alignment-aware allocators would be unable to allocate the required number= =20 of bytes if the alignment is incorrect. (e.g. =E2=80=93 The caller requests= =20 alignment on 16 byte boundaries, but the allocator only supports alignment= =20 on 4 or 8 byte boundaries.) If the allocator throws a bad_alloc exception= =20 for the invalid alignment, the caller may assume the program is out of=20 memory instead of assuming the alignment is incorrect. Such a caller may=20 call a new_handler believing it will make more memory available. A=20 new_handler could spend an enormous amount of time looking for memory that= =20 is available only to find none, simply throw another bad_alloc exception,= =20 or terminate the program by calling std::abort or std::exit. None of these= =20 actions will resolve the simple problem of using the correct alignment. A caller that is correctly informed the alignment is invalid could merely= =20 repeat the request with a different alignment value. This is a low cost=20 action that provides the intended result =E2=80=93 allocating a chunk of me= mory=20 with the correct alignment. This means that a bad_alloc exception with a valid explanatory string could= =20 provide the caller with actionable information to solve the problem, while= =20 a bad_alloc exception with no (or an inaccurate) explanatory string would= =20 lead the caller to perform an expensive or program-ending action. When the std::align_val_t parameter is added to class-specific new and=20 delete operators, users will be able to choose alignments that are not=20 supported by the allocators they use. (This proposal assumes the global new= =20 and delete operators will support all alignment values in the=20 std::align_val_t type, and thus it will be impossible to call a global=20 memory operator with an invalid alignment value.) =20 *5. **Allowing allocators to inform callers exactly why allocations=20 failed.* Allocations may fail for reasons other than the program ran out memory.=20 There are specialized allocators that only handle requests for specific=20 sizes, such as pool allocators, that could throw exceptions if they receive= =20 requests for sizes they cannot handle. This example shows how an allocator might throw a bad_alloc exception with= =20 actionable information. void * PoolAllocator::Allocate( std::size_t bytes, std::align_val_t=20 alignment ) { if ( ( bytes < minAllowedSize ) || ( maxAllowedSize < bytes ) ) { throw *SmartBadAllocException(* *=E2=80=9CError! This allocator only handles allocations from 16 through 64= bytes=20 in size.=E2=80=9D, __LINE__, __FUNCTION__ );* } if ( !IsValidAlignment( alignment ) ) { throw *SmartBadAllocException(* *=E2=80=9CError! This allocator only handles alignments on 4 byte boundarie= s.=E2=80=9D,=20 __LINE__, __FUNCTION__ );* } void * place =3D FindPlace( bytes, alignment ); if ( place =3D=3D nullptr ) { throw SmartBadAlloc( =E2=80=9CError! Unable to allocate bytes.= =E2=80=9D, __LINE__, __FUNCTION__ ); } return place; } =20 IV. Impact on the Standard=20 =20 =C2=B7 Implementing this proposal will have minimal impact on the C= ++=20 Standard. =C2=B7 It is a pure extension that does not break any existing code= .. =C2=B7 It does not require additional changes to any library or the= =20 existing language. =20 V. Design Decisions=20 This proposal brings up various questions. 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? 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 not= =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. =20 VI. Acknowledgements=20 Many thanks to the following people who reviewed various drafts of this=20 proposal and provided feedback. 1. Herb Sutter 2. Andrei Alexandrescu =20 VII. References=20 =20 1. http://en.cppreference.com/w/cpp/memory/new/bad_alloc 2. http://en.cppreference.com/w/cpp/error/logic_error 3. http://en.cppreference.com/w/cpp/memory/new/operator_new 4. http://en.cppreference.com/w/cpp/memory/new/operator_delete 5. http://en.cppreference.com/w/cpp/memory/new/set_new_handler --=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/d9001051-0946-4dcf-bf78-8bcdb8302989%40isocpp.or= g. ------=_Part_2953_1219705336.1504294124651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I wrote this proposal after discovering the std::bad_all= oc exception class only has a default constructor. Other exception clas= ses have constructors with a string parameter. The lack of a similar constr= uctor in bad_alloc has caused problems for me.

This is the second dr= aft of this proposal. Please provide feedback on how to improve it before I= submit it.

I would especially prefer feedback on wording and style = so that it conforms with the wording and style of accepted proposals. I wou= ld also like feedback on technical correctness.

If anybody has insig= hts on upcoming changes to the standard exception classes that might affect= this proposal, please let me know.

If you prefer a Word document ve= rsion of this proposal, please let me know.

Thanks,

Rich Spos= ato

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The bad_alloc C= onstructor Parameter Proposal

=C2=A0<= /p>

By Rich= ard Sposato

Septemb= er 2017

Contents

I.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Introduction. 1

II.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Technical Specifications. 1

III.=C2=A0=C2=A0=C2=A0 Motivation. 2

IV.=C2=A0=C2=A0=C2=A0 Impact on the Standard. 5

V.=C2=A0=C2=A0=C2=A0=C2=A0 Design Decisions. 5

VI.=C2=A0=C2=A0=C2=A0 Acknowledgements. 5

VII.=C2=A0=C2=A0 References. 5

=C2=A0

=C2=A0

I.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Introduction


A proposal to add two constructors to the std::bad_alloc class so it conforms= to other exception classes.


Intended Audience:

These changes are inte= nded for C++ programmers of intermediate through expert skill level who are either autho= rs or users of memory allocation libraries.

=C2=A0

II.=C2=A0=C2=A0=C2=A0=C2=A0 Technical Specifications

The current implementation of bad_alloc class supports only the default constructor. To avoid breaking existing code, this constructor will continu= e to exist, and will provide an implementation defined explanatory string for th= e what() function.


bad_alloc();


The two additional constructors will accept either a reference to const std::string= or a pointer to a C-style string. These constructors will look identical to constructors in other exception classes.

explicit bad_alloc( const std::string & what_arg );

explicit bad_alloc( const char * what_arg );


An alternate constructor would use a string_view parameter instead of either o= f the two above constructors.

explicit bad_alloc( std::string_view what_arg );

=C2=A0

Each will construct a bad_alloc exception object that stores what_arg as an explanato= ry string that can be accessed through the what() function.

=C2=A0

III.=C2=A0 Motivation


There are several moti= vations for this proposal. Each of these will be described in detail.

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Conformance to existin= g exception classes.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ease of making templat= es that construct exceptions.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ease of deriving subcl= asses from exception classes.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Changes to C++17 new a= nd delete operators.

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Allowing allocators to= inform callers exactly why allocations failed.

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Conformance to existing exception classes.


All other exception cl= asses in the std namespace provide constructors that accept either a single parameter of eit= her a reference to a const std::string or a pointer to a C-style string. The parameter provides a human-readable explanation for why the program threw a= n exception or actionable information allowing the calling code to correct th= e problem.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 logic_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 invalid_argument

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domain_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 length_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 out_of_range

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 runtime_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 range_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 overflow_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 underflow_error

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tx_exception


Conformance to other e= xception classes will enable motivations two and three for this proposal.

=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ease of making templates that construct except= ions.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ease of deriving subclasses from exception cla= sses.


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.


Classes that derive fr= om the standard exceptions cannot call the bad_alloc constructor using the same co= de they would to call other exception classes. This example illustrates how to= wrap existing exception classes with a smart-exception class that derives from standard exceptions.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sma= rtException( const char * message,

unsigned int line, con= st char * function ) :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ExceptionType( message ),

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 line_( line ),

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 functionName_( function )

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {}<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // = .... rest of class ...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uns= igned int line_;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 con= st char * functionName_;


The SmartException con= structor will call a subclass constructor that accepts a string parameter. This works for most exceptions, but not bad_alloc.


These lines define var= ious smart exceptions using the above class and typedefs.


typedef SmartException= < std::bad_alloc > SmartBadAllocException;

typedef SmartException= < std::logic_error > SmartLogicErrorException;


This function shows ho= w code would throw a smart exception so any code catching the exception can report exact= ly where the problem occurred.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 voi= d * place =3D FindPlace( bytes, alignment );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if = ( place =3D=3D nullptr )

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 throw SmartBadAllocException( =E2=80=9CError! Un= able to allocate bytes.=E2=80=9D,

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 __LINE__, __FUNCTION__ );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret= urn place;

=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Changes to C++17 new and delete operators.


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.


=C2=A0

Alignment-aware allocators would be unable to allocate the required number of bytes if the alignment is incorrect. (e.g. =E2=80=93 The caller requests alignment on 16= byte boundaries, but the allocator only supports alignment 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. Such a caller may call a new_handler b= elieving it will make more memory available. A new_handler could spend an enormous amount of time looking for memory that is available only to find none, simp= ly throw another bad_alloc exception, or terminate the program by calling std::abort or std::exit. None of these actions will resolve the simple prob= lem of using the correct alignment.


A caller that is correctly informed the alignment is invalid could merely repeat the request with a different alignment value. This is a low cost action that provides the intended result =E2=80=93 allocating a chunk of memory with th= e correct alignment.


This means that a bad_alloc exception with a valid explanatory string could provide the cal= ler with actionable information to solve the problem, while a bad_alloc excepti= on with no (or an inaccurate) explanatory string would lead the caller to perf= orm an expensive or program-ending action.


When the std::align_val_t parameter is added to class-specific new and delete operat= ors, users will be able to choose alignments that are not supported by the alloc= ators they use. (This proposal assumes the global new and delete operators will support all alignment values in the std::align_val_t type, and thus it will= be impossible to call a global memory operator with an invalid alignment value= ..)

=C2=A0

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Allowing allocators to inform callers exactly = why allocations failed.


Allocations may fail f= or reasons other than the program ran out memory. There are specialized allocators tha= t only handle requests for specific sizes, such as pool allocators, that coul= d throw exceptions if they receive requests for sizes they cannot handle.


This example shows how= an allocator might throw a bad_alloc exception with actionable information.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if = ( ( bytes < minAllowedSize ) || ( maxAllowedSize < bytes ) )

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 throw SmartBadAllocException(=

=E2=80=9CError! This allocator only handles allocations from 16 = through 64 bytes in size.=E2=80=9D, __LINE__, __FUNCTION__ );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if = ( !IsValidAlignment( alignment ) )

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 throw SmartBadAllocException(=

=E2=80=9CError! This allocator only handles alignments on 4 byte boundaries.=E2=80=9D, __LINE__, __FUNCTION__ );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 voi= d * place =3D FindPlace( bytes, alignment );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if = ( place =3D=3D nullptr )

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 throw SmartBadAlloc( =E2=80=9CError! Una= ble to allocate bytes.=E2=80=9D,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __LI= NE__, __FUNCTION__ );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret= urn place;

=C2=A0

IV. Impact on the Standard

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Implementing this prop= osal will have minimal impact on the C++ Standard.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 It is a pure extension= that does not break any existing code.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 It does not require ad= ditional changes to any library or the existing language.

=C2=A0

V.=C2=A0=C2=A0=C2=A0 Design Decisions


This proposal brings u= p various questions.


1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should the bad_alloc e= xception 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 fo= r 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 fo= r allocations that fail because of internal problems with the allocator?


One answer to the firs= t 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 programm= ers 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.

=C2=A0

VI. Acknowledgements


Many thanks to the fol= lowing people who reviewed various drafts of this proposal and provided feedback.<= /p>


1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Herb Sutter

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Andrei Alexandrescu

=C2=A0

VII.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 References

=C2=A0

1.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 http://en.cppreference= ..com/w/cpp/memory/new/bad_alloc

2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 http://en.cppreference= ..com/w/cpp/error/logic_error

3.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 http://en.cppreference= ..com/w/cpp/memory/new/operator_new

4= ..=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 http://en.cppreference= ..com/w/cpp/memory/new/operator_delete

5.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 http://en.cppreference= ..com/w/cpp/memory/new/set_new_handler

--
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/d9001051-0946-4dcf-bf78-8bcdb8302989= %40isocpp.org.
------=_Part_2953_1219705336.1504294124651-- ------=_Part_2952_496205681.1504294124648-- .