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