> On 28 Mar 2018, at 20:46, Jonathon Jongsma <jjong...@redhat.com> wrote: > > On Wed, 2018-03-28 at 17:42 +0200, Christophe de Dinechin wrote: >> Somewhat OT, but hopefully informative in the context of this thread. >> >> >>> On 26 Mar 2018, at 18:24, Jonathon Jongsma <jjong...@redhat.com> >>> wrote: >>> >>> As teuf mentioned in a different email, std::runtime_error in C++11 >>> has a const char* constructor: >> >> Since the presence of this constructor was used repeatedly as an >> argument, I’ve asked a few times if someone could tell me why this >> constructor was added in C++ 11. So far, nobody answered. I did not >> think it was so hard to google it. Oh well, since nobody else took up >> the challenge, time for me to answer the question… >> >> Here is one source giving a relatively short explanation: https://sta >> ckoverflow.com/questions/29052647/c11-introduced-exception- >> constructors-taking-const-char-but-why. I quote: "This allows (or at >> least is apparently intended to facilitate--see more below) the >> implementation to eliminate copies in cases where it can detect (by >> means that are not themselves standardized) that what's being passed >> is a string literal or something else with static storage duration.” >> See also the note at the end of that answer: "[ Oxford: The proposed >> resolution simply addresses the issue of constructing the exception >> objects with const char* and string literals without the need to >> explicit include or construct a std::string. ]” >> >> So what happened is that the committee knew that having an >> std::string constructed for all runtime errors was problematic, as >> far back as 2000. This is defect 254, see http://std.dkuug.dk/jtc1/sc >> 22/wg21/docs/lwg-closed.html. It was a bit annoying if implementors >> took a great deal of care and effort to ensure that you could throw >> an exception reliably in low-memory situations (see section 4.2.2 of >> https://github.com/itanium-cxx-abi/cxx-abi/blob/master/HP-exception-9 >> 90818.pdf if you are curious about the kind of shenanigans I’m >> talking about) only to see all these effort thwarted by the (legacy) >> interface of std::runtime_error. >> >> However, you can imagine that back in 2000, deciding to remove the >> std::string constructor was difficult. So the problem was not easy to >> fix, and it shouldn’t be too hard to believe that there was a lot of >> discussion (254 is listed as one of the hot topics for the Redmond >> meeting). Before the Oxford meeting, the decision was to accept >> throwing bad_alloc as a fact of life. But as you can see at the >> bottom of bug 254, the consensus on a better longer-term resolution >> for C++0x, which became C++11, was to add a const char * that would >> allow the implementation to special-case std::runtime_error and avoid >> the copy. In the Oxford meeting, that resolution was confirmed, and >> the change made it to C++11. >> >> Out of curiosity, I checked both clang and g++, and they don’t >> actually store a string in std::runtime_error, I suspect in large >> part because of another related issue, namely the risk of throwing >> from string copy constructors. though they don’t seem to be doing the >> optimization either, because it’s quite hard relative to the benefits >> :-( So no worries, on clang, if you are really out of memory, you >> will not throw bad_allloc or end up in terminate(). No sir, the >> standard forbids it. No, instead, you will segfault writing into a >> null pointer (line 74 of https://llvm.org/viewvc/llvm-project/libcxx/ >> trunk/src/include/refstring.h?view=markup if you are curious). So >> much better. >> >> Bottom line: the very reason there is a const char * constructor in >> std::runtime_error is to provide a workaround for a known design bug. >> There is no value in blindly repeating that design bug. >> >> >> Cheers, >> Christophe >> >> _______________________________________________ >> Spice-devel mailing list >> Spice-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/spice-devel > > > This doesn't seem like a fruitful discussion any longer.
It’s long been unproductive, only blocking my patch series for no good reason. > I disagree > with your opinion that *for our use cases* it's more desirable to avoid > a small memory allocation than to make the class more resilient to > programmer error. But you clearly won't be convinced, and it's not the > most important issue in the world. So I'll withdraw from this > discussion. And I find it distasteful that you still insist using std::string would make it “more resilient to programmer error” when I’ve proven it was not the case and spent an inordinate amount of time explaining why. Christophe > > Jonathon > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
