[PING] Re: Add const char* constructors for exception classes in <stdexcept>

[Oleg Endo]

Jonathan,

now that we're in stage 1 again, I'd like to revive the issue below.  Do
you have any particular plans?  How should we proceed?

Cheers,
Oleg

On Wed, 2014-01-29 at 23:45 +0100, Oleg Endo wrote:
> On Wed, 2014-01-29 at 21:38 +0000, Jonathan Wakely wrote:
> > On 29 January 2014 21:17, Oleg Endo wrote:
> > > My original intention was to eliminate code bloat when doing something
> > > like  throw std::logic_error ("cold coffee");
> > > If the const char* overloads are inlined it will emit code to construct
> > > an std::string from const char* in user code where the exception is
> > > being constructed over and over again.  The idea was to move that code
> > > into the std library.
> > 
> > That's exactly what happens today with the constructors that only take
> > a std::string, so it wouldn't be any worse than what we have now,
> > would it?
> 
> Sorry, I'm not sure I understand your question.  Maybe you meant "any
> better than what we have"?  Anyway, I've attached two outputs that show
> what I mean.  The version with the const char* ctor overloads
> implemented in the library is significantly shorter in the throwing path
> (5x function call vs. 7x function call + other inlined std::string ctor
> code).
> 
> > 
> > > BTW the original patch was posted during Stage 3 (19.12.2013).  I don't
> > > mind waiting until Stage 1 if adding exports now is a problem.
> > 
> > OK, let's wait and decide how we want to do it properly in stage 1.
> 
> Sure.  Actually I've missed some of the other exception types in
> system_error, which should be added, too.  That would eliminate the
>    TODO: Add const char* ctors to all exceptions.
> 
> I'd also propose moving the system_error ctor implementations into the
> library as well, for the same reasons as above.
> 
> > 
> > (If we're going to make various changes that impact the ABI during the
> > next stage 1 we might even want to consider changing the
> > std::exception base class to store something like a
> > std::shared_ptr<std::string> so that copying an exception object will
> > never throw an exception, which is something I've been thinking about
> > recently.)
> 
> Wouldn't using std::shared_ptr<std::string> introduce an additional heap
> allocation when creating the exception, though?
> How about storing the exception message in a plain zero terminated
> string instead?  This would require only one heap allocation if the
> string data is prefixed with a refcount variable.  Basically,
> std::make_shared re-invented because it doesn't work with arrays.
> Or maybe implement N3640 + N3641 first (even if for library internal use
> only as a start)...
> 
> Cheers,
> Oleg