220 34264 <42389eb4-97a9-4a1d-bbfb-c653ba62097f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to add constructors to std::bad_alloc exception class. Date: Fri, 1 Sep 2017 16:04:17 -0700 (PDT) Lines: 1050 Approved: news@gmane.org Message-ID: <42389eb4-97a9-4a1d-bbfb-c653ba62097f@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3111_1365216330.1504307057642" X-Trace: blaine.gmane.org 1504307063 15876 195.159.176.226 (1 Sep 2017 23:04:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 23:04:23 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB4WOU7GQKGQE3XVB6GY@isocpp.org Sat Sep 02 01:04:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnuyy-0003Zo-JQ for gclcip-std-proposals@m.gmane.org; Sat, 02 Sep 2017 01:04:13 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id p2sf1480852ite.19 for ; Fri, 01 Sep 2017 16:04:20 -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=8cM/3M32hA7nRyo9nQLmq2sdz07QAPTSiD4wlCIgj9g=; b=C0nk90NJB9ly7mVpsgsvdBIG+NSp+FaKmICF3pxJqWyM524RJzyVhsZSS74hUhaO9k KFEVPi4dGPiVEXHNNaf/mYJX2DmwM7K9fJ5L8c0gLIKcYsDHdgYy/4an86TCnyE30Q0e HNVdWyIlO85tpQ9lkZObIKngHjA2m86M/Yc+f4KvJlTnrOrHZHjBSDqNp1v9Ltp48Qzp Q5D4/K7fwTb6idABx7JtbyYV4CicWPMoXthgzcJr1/dd6Eh6IqAkSpFcjVGPSsqlFzel CKPNRS1yDSFJrDt9peSnGF7ZvaORQks5Cqz1UhnsXy4Nnls2ttJ/PGm0alCnIpaekyz3 tepQ== 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=8cM/3M32hA7nRyo9nQLmq2sdz07QAPTSiD4wlCIgj9g=; b=n/QdQZilbHf6D624T5+Uk9UV1egcwe80/jAv5rzX8sT99CVoGSU/DeDT0Kmxjgd5pz GST1361IXGJlkLLDTDheLUdUZO4aMz4yRyZYDcu60swj9Dxhio9H7nSY+AyPn1Vs2mZF y6KIo11zpIizldXMXV+ilRxfVdrQJAfkXHEfGE7B+57B+6iNIFe7muccs3zXzjcToMAH XxiqJ0u0lsbEizTqsIWBXxMY7FK9cNzT7V0a4ZJcplVInF3iNRKIYBwzZvSGKRyyu2dK i+6EbRC8XufKQBns3maY6+RSNUj6d8q3Qvx5uL7qTUpV11aLgJjlHXGgJ9QAbU4XcFy9 YIGQ== 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=8cM/3M32hA7nRyo9nQLmq2sdz07QAPTSiD4wlCIgj9g=; b=OG9lGzVj5eE/A3TxXFQU9YOS5iUFuTzJqAoIvVr1a+V/YVN1pUbMVOlxZaoHfPLSae cO78rJy4F1ueUhuXc89MXt4XHcQ3vGx/M76sEK3G18EDu+dnkMavybTRR+cfzrLG2hRp BeEcDf0e4n6ZGBoQdH3vS1x5yBzahB0TeR5PCJzJpFRhHgMGxy0XxfNjcNzkcAs4YHM7 qgugWE264kxTWAgQQUIMgDRjSPrKuCRHFREcaBe3BYYt/lw4MOYiryicpHc20nTJ5dqB S9r3MxyEPHoePf2PL+i71+GZmETV4acxEkEFXZ6bsQFdcqtABfd4gHwPHKJSiMesOb0l HieA== X-Gm-Message-State: AHPjjUjmvHJKUvQl9LtNfH5ju5W3fSDfxP6oBJFlASv6Qss+l5ktUoXi iAWG4WukP9PmRnyN X-Google-Smtp-Source: ADKCNb51F0M6lHykzoRB1dfn/QdcDPUHn1nOdwHsH5u480prr8zVyRuJR90R0Ka3/06ErbFSaFOQjA== X-Received: by 10.36.83.208 with SMTP id n199mr1707703itb.48.1504307059521; Fri, 01 Sep 2017 16:04:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.38.74 with SMTP id m71ls2446520iom.10.gmail; Fri, 01 Sep 2017 16:04:18 -0700 (PDT) X-Received: by 10.31.179.198 with SMTP id c189mr98863vkf.28.1504307058127; Fri, 01 Sep 2017 16:04:18 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:34264 Archived-At: ------=_Part_3111_1365216330.1504307057642 Content-Type: multipart/alternative; boundary="----=_Part_3112_740863468.1504307057644" ------=_Part_3112_740863468.1504307057644 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, September 1, 2017 at 3:28:44 PM UTC-4, Rich Sposato wrote: > > 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. > Overall, I find your proposal poorly motivated. See below for details. But= =20 this proposal needs better motivation for its existence. =20 > 1*. **Conformance to existing exception classes.* > > > All other exception classes in the std namespace provide constructors tha= t=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. > As others have pointed out, `std::bad_alloc` is special because it is due= =20 to exactly the kind of failure that your API simply cannot handle: the=20 ability to allocate memory. For the rest of my examinations, I will assume that the API is such that it= =20 takes a bare `const char*`, and passes it on directly, with the expectation= =20 being that you will ensure that the memory being pointed to will live to=20 the catch site. Because without that, I'm fairly sure your proposal is=20 essentially DOA. *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 example that uses both templates and=20 > inheritance to show why bad_alloc constructors should accept an explanato= ry=20 > string parameter. > > > Classes that derive from the standard exceptions cannot call the bad_allo= c=20 > constructor using the same code they would to call other exception classe= s.=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. > Here's a much better version, one that can work with *any* exception class= =20 type, not just the ones that take a string: template class LocalizedException : Exception { template LocalizedException(unsigned int line, const char * function, Args &&args) : Exception(std::forward(args)...) , line_(line) , function_(function) {} }; Now, isn't that much better? You're not forcing yourself into this=20 erroneous "all exceptions take strings when constructed" assumption. You=20 can work with other types, those that have their own messages or whatever. *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 numbe= r=20 > of bytes if the alignment is incorrect. (e.g. =E2=80=93 The caller reques= ts=20 > alignment on 16 byte boundaries, but the allocator only supports alignmen= t=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 tha= t=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 thes= e=20 > actions will resolve the simple problem of using the correct alignment. > That sounds like a good reason to separate `bad_alloc` from=20 `bad_alignment`. What we *don't* want is for users to try to do this: catch(std::bad_alloc &e) { if(e.what() =3D=3D ...) { //Handle bad alignment } else { //Handle OOM. } } That's two catch statements macarading as one. That's bad coding. =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 recei= ve=20 > requests for sizes they cannot handle. > > > This example shows how an allocator might throw a bad_alloc exception wit= h=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 boundar= ies.=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; > > } > Unless you write an English language parser to figure out what those mean,= =20 the only "actionable" thing that can be done is by the *programmer* (aka:= =20 spitting the message out to the log), not by the program itself. The only way to make this detectable by the program itself is to have it=20 throw something other than (or more than) `bad_alloc`. None of which=20 requires playing games with its string. =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/42389eb4-97a9-4a1d-bbfb-c653ba62097f%40isocpp.or= g. ------=_Part_3112_740863468.1504307057644 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, September 1, 2017 at 3:28:44 PM UTC-4, Rich Spo= sato wrote:

III.=C2=A0 Motivation


There are several motivations for this proposal. Each of these will be described in detail.

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Conformance to existing e= xception classes.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Ease of making templates = that construct exceptions.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Ease of deriving subclass= es from exception classes.

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

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


Overall, I = find your proposal poorly motivated. See below for details. But this propos= al needs better motivation for its existence.
=C2=A0

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


All other exception classes 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 exception classes will enable motivations two and three for this proposal.

=

As others have pointed out, `std::bad_alloc` is special becau= se it is due to exactly the kind of failure that your API simply cannot han= dle: the ability to allocate memory.
For the rest of my examinations, I wil= l assume that the API is such that it takes a bare `const char*`, and passe= s it on directly, with the expectation being that you will ensure that the = memory being pointed to will live to the catch site. Because without that, = I'm fairly sure your proposal is essentially DOA.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ease of making templates that construct exceptions.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ease of deriving subclasses from exception classes.


Motivations #2 and #3 are related.

They can be explained with a single example that use= s both templates and inheritance to show why bad_alloc constructors should accept an explanatory string parameter.


Classes that derive from 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.

template < = class ExceptionType >

class SmartExc= eption

{

public:=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SmartException( cons= t char * message,

unsigned int line, cons= t 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 {}

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

private:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int line_;<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const char * functio= nName_;

};


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


Here's a mu= ch better version, one that can work with any exception class type, not just the ones that take a string:

template<class Exception>class LocalizedException : Exception
{
=C2=A0 template<typename .= ...Args>
=C2=A0 LocalizedException<= /span>(unsigned int line, const char * function, Args &&args)
=C2=A0 =C2=A0 : Exception(std::forward<Args>(args)...)
=C2=A0 =C2=A0 , line_(line)
=C2=A0 =C2=A0 , function_(function)

=C2=A0 {}

};

Now, isn't that much better? You're not forcing yoursel= f into this erroneous "all exceptions take strings when constructed&qu= ot; assumption. You can work with other types, those that have their own me= ssages or whatever.

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.


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 );

=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.


That sounds like a = good reason to separate `bad_alloc` from `bad_alignment`. What we don't want is for users to try to do this:
=

catch(std::bad_alloc &e<= /span>)
{
=C2=A0 if(e.what= () = =3D=3D ...)
=C2=A0 {
=C2=A0 =C2=A0 //Handle bad alignment
=C2=A0 }
=C2=A0 else
=C2=A0 {
=C2=A0 =C2=A0 //Handle OOM.
=C2=A0 }
}

That's two catch statements macarading as one. That's = bad coding.
=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 for 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.


void * PoolAl= locator::Allocate( std::size_t bytes, std::align_val_t alignment )

{

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ( ( bytes < mi= nAllowedSize ) || ( 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 f= rom 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 ( !IsValidAlignme= nt( 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 void * place =3D Fin= dPlace( bytes, alignment );

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if ( place =3D=3D nu= llptr )

=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! Unable 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 return place;=

}


Unless you write an English language parser to figure out what = those mean, the only "actionable" thing that can be done is by th= e programmer (aka: spitting the message out= to the log), not by the program itself.

The only way to make this detectab= le by the program itself is to have it throw something other than (or more = than) `bad_alloc`. None of which requires playing games with its string.
=C2=A0

--
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/42389eb4-97a9-4a1d-bbfb-c653ba62097f= %40isocpp.org.
------=_Part_3112_740863468.1504307057644-- ------=_Part_3111_1365216330.1504307057642-- .