> On 28 Mar 2018, at 22:32, Christophe de Dinechin <cdupontd@xxxxxxxxxx> wrote: > > > >> On 28 Mar 2018, at 20:46, Jonathon Jongsma <jjongsma@xxxxxxxxxx> 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 <jjongsma@xxxxxxxxxx> >>>> 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@xxxxxxxxxxxxxxxxxxxxx >>> 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. By which I mean among other things what I wrote earlier today: > Therefore, it is important for the interface of Error to “strongly suggest” constant strings where I want constant strings. By the mean of a “const char *”. Where I expect a dynamic string, I use std::string (or const std::string & or whatever floats you boat). As long as you keep ignoring that point, as long as you keep ignoring that detecting an inadvertent use of std::string input is actually *by design* and *desirable*, you have not understood that your proposal *in our use case* makes things significantly *less* resilient to the most important class of programmer error, where a programmer would mistakenly attempt to pass something like “can’t write “ + file. So you will keep blocking this patch indefinitely because you don’t understand it. And I find this unacceptable. Christophe > > Christophe > >> >> Jonathon >> _______________________________________________ >> Spice-devel mailing list >> Spice-devel@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/spice-devel > > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel