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
