+1

I work in industry where functional safety is important and exceptions are
primarily prohibited due to undeterministic worst case execution time.

Br,
Intars


On Tue, 22 Oct 2019, 20:01 Sophia Poirier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I work in industries with realtime-sensitivity where turning exceptions
> off is common and *always* due to the performance overhead.
>
> - Sophia
>
>
> On Oct 22, 2019, at 1:23 AM, Dmitry via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> I, personally, think that a lot of people are "fighting a strawman",
> trying to address wrong questions.
>
> The main problem with exceptions (and therefore, the reason why they are
> banned) is not overhead, but their "implicit-ness".
> People want to understand what is going on (I mean, is it possible to have
> an error in this particular function or not, and which error exactly)
> without having to recall each line in the entire codebase, but rather by
> looking on the signature of a function.
> The property of locality if very important - that is exactly what OOP is
> about - being able to reason about code, without having to remember distant
> part of codebase is crucial. Herb's exceptions do not do much in this
> regard...
>
> I have already posted here my take on the topic, but in case you missed
> it, here it is
> <https://www.reddit.com/r/cpp/comments/cliw5j/should_not_exceptions_be_finally_deprecated/>
> .
>
> On Sat, 5 Oct 2019 at 06:39, Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> “Section 3 seems out-of-place. You're switching from a conservative
>>> critique of Herb's existing proposal, to an even wilder proposal of your
>>> own? Flying cars will never work, but let me tell you my ideas on personal
>>> jetpacks?”
>>>
>>>
>>> What is the point of criticizing other people’s works without providing
>>> solution? Complaining for no reason?
>>>
>>
>> Well, you should be able to deal with the merits (or lack thereof) of
>> Herb's proposal completely orthogonally to your own "solution."
>> Your paper has two different things going on:
>> (1) a critique of Herb's proposal, which I think makes some valid points
>> and some invalid points;
>> (2) a promotion of your own proposal [Java-style checked exceptions +
>> noexcept(auto)], which I think is much more flawed than Herb's.
>> Right now you're tying those two orthogonal issues together. In my
>> opinion, the naivete of (2) reduces your credibility in re (1). Someone
>> else might disagree with (1), and then view (2) as irrelevant.
>>
>>
>>
>>> “Your `dynamic_exception` type sounds exactly isomorphic to C++11 `
>>> std::exception_ptr
>>> <https://en.cppreference.com/w/cpp/error/exception_ptr>`. Have you seen
>>> `exception_ptr` before? After looking at `exception_ptr`, what differences
>>> do you see between `exception_ptr` and your ideas about
>>> `dynamic_exception`?”
>>>
>>>
>>>
>>> I agree dynamic_exception is a fault. I have a new solution to that
>>> which is throws exception should not be allowed to be bound to a pointer or
>>> virtual function, just like constexpr. If people want that, they need to
>>> use current exception. I will provide a revised version of my proposal in
>>> the next few days.
>>>
>>
>> Please, take a look at std::exception_ptr on cppreference. See if it does
>> what you're looking for.
>>
>>
>> In general, variant-based exception works and it is the only real
>>> zero-overhead exception proposal.
>>>
>>
>> When you use phrases like "real zero-overhead", it makes me think that
>> you're exaggerating or naïve.
>> C++ exceptions are "zero-overhead" in the sense that you don't pay for
>> test-and-branch at each level of a successful call stack; but they are
>> "non-zero overhead" in many other ways. Your proposed exception mechanism,
>> like Herbceptions, is "zero-overhead" in the sense that you don't need any
>> auxiliary data tables to tell you how to perform stack unwinding; but it is
>> "non-zero overhead" in the sense that it inserts test-and-branch
>> instructions at each level of the call stack, slowing down your code's
>> happy path.
>>
>>
>> - "Sutter thinks exceptions and RTTI are the only two violators of the
>>> zero-overhead principle."
>>> That is true. Herb Sutter did say that in his video and his paper.
>>>
>>> “RTTI is the other C++ language feature that violates the zero-overhead
>>> principle. [...]"
>>>
>>
>> Good. Cite this in your paper.
>> Don't just claim or assert it; provide *evidence* for your claim. If
>> that means linking to YouTube, or to another committee paper, do so!
>>
>>
>> - "Introducing a new keyword is a problem." Introducing a new contextual
>>> keyword `throws`, in the same place as `override` and `final`, is actually
>>> not troubling at all. By pretending that it is a problem, you cast doubt on
>>> the rest of your arguments.
>>>
>>>
>>>
>>> False. As Bjrane demoed in the previous cppcons Even introducing nullptr
>>> would cause problem since it is possible some people are using nullptr as
>>> variable name. Same thing with why coroutine keywords are called co_yield,
>>> co_return instad of yield or resume
>>>
>>
>> `override`, `final`, and Herb's `throws` keyword are not a problem for
>> C++'s grammar in the way that e.g. `yield` is.
>> For more information on the grammar of contextual keywords, see N3163
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3163.pdf>.
>>
>>
>> - "The prototype has not completed yet." (by which you mean "there is no
>>> implementation of std::error available") Quite possibly true, but I would
>>> like to see a link to a GitHub or something. I bet someone has at least
>>> tried to implement it, right? No?
>>>
>>>
>>>
>>> 14ned’s implementation is horrible and not freestanding.
>>>
>>
>> So, someone *has* tried to implement it? I'd like to see your paper
>> offer a link to that implementation.
>> It would also be interesting to see *why* you think that implementation
>> is "horrible."
>> Maybe you could come up with a code snippet (on Compiler Explorer, for
>> example) that shows a significant difference in performance between that
>> implementation and the optimal one.
>>
>> - "A lot of middle school algorithm competition like NOIP is banning
>>> containers or not enabling optimization toggle." Citation wanted.
>>>
>>>
>>>
>>> Evidence?
>>>
>>
>> Yes. Again, in the form of a link, in the paper.
>> http://www.noi.cn/newsview.html?id=67&hash=2DA1FD&type=6 counts as
>> evidence. Put it in the paper.
>> (Although, uncharitably, I wonder why these rules are 10 years old and
>> exist only in Chinese. The rules for the 2019 International Olympiad in
>> Informatics are here <https://ioi2019.az/en-content-26.html>, and they
>> don't mention any banned headers.)
>>
>>
>> - "C++ code still cannot run on a lot of platforms with no ABIs of
>>> dynamic exceptions, web assembly, for example." Is this saying that C++
>>> compilers targeting WebAssembly can't use try/throw/catch? Citation wanted.
>>>
>>>
>>>
>>> It just aborts. Why do you not even watch Cppcon 2019?
>>>
>>> https://youtu.be/5N4b-rU-OAA?t=4690
>>>
>>
>> I've watched it now, thanks! I had not watched that link before you sent
>> it because I'm not a mind-reader. Put it in your paper.
>>
>> –Arthur
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>
> --
> Dmitry
> *Sent from gmail*
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>