This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PING] Re: Add const char* constructors for exception classes in <stdexcept>
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 01 May 2014 18:18:12 +0200
- Subject: Re: [PING] Re: Add const char* constructors for exception classes in <stdexcept>
- Authentication-results: sourceware.org; auth=none
- References: <1387411826 dot 2455 dot 325 dot camel at yam-132-YW-E178-FTW> <CAH6eHdTK93RwatvT+m_1TLv7Ni=yQ=wDi6v7Hq=jT=O=ZSffzw at mail dot gmail dot com> <1387466908 dot 2455 dot 355 dot camel at yam-132-YW-E178-FTW> <1390745736 dot 22215 dot 207 dot camel at yam-132-YW-E178-FTW> <20140129152136 dot GA21735 at redhat dot com> <1391030247 dot 13654 dot 9 dot camel at yam-132-YW-E178-FTW> <CAH6eHdQXvD27Y83cpEtoJRH7=3mAfujzd4=GKDBiT-G08SK-pg at mail dot gmail dot com> <1391035518 dot 13654 dot 34 dot camel at yam-132-YW-E178-FTW>
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?
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
> > > 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)...