I’ll Invite FrankHB (Top1 C++ expert in China) to the debate. He thinks sutter’s proposal ruins everything as well like I think.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: sotrdg sotrdg<mailto:euloanty_at_[hidden]>
Sent: Friday, October 4, 2019 22:08
To: Arthur O'Dwyer<mailto:arthur.j.odwyer_at_[hidden]mail.com>; hsutter_at_[hidden]<mailto:hsutter_at_[hidden]>
Subject: FW: [std-proposals] FW: Reply to Herb Sutter about Zero-Overhead deterministic. It is not true.

“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?


“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.


I have read all papers and arguments about the entire issue. I have seen the prototype of std::error. std::error prototype is a fault.

BTW, current exception is NOT that bad as Sutter’s claims. He is wrong. Also you must be native to think this throws exception will solve issues like binary bloating.

In general, variant-based exception works and it is the only real zero-overhead exception proposal.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


From: sotrdg sotrdg
Sent: Friday, October 4, 2019 10:00:03 PM
To: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>; hsutter_at_[hidden] <hsutter_at_[hidden]>; ISO C++ Standard - Future Proposals <std-proposals_at_[hidden]>
Subject: RE: [std-proposals] FW: Reply to Herb Sutter about Zero-Overhead deterministic. It is not true.

I’ll provide you a full rely of my refute and evidence.


- "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. We need to fix RTTI too, but this is not that paper. However, because exceptions rely on RTTI (by propagating and manipulating dynamically typed exceptions) so that the cost of RTTI is indirectly part of the exception handling cost, here is a brief summary of why RTTI violates zero-overhead and the two issues that most directly affect exception handling: 2”


- "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

- "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. Again, the prototype itself violates zero-overhead principle since he has to put another variable on some place which will waste storage. It does not work in embedded system, just like why <new> <exception> is a fault in freestanding implementation.

- "A lot of middle school algorithm competition like NOIP is banning containers or not enabling optimization toggle." Citation wanted.

Evidence?
These headers are banned

C++程序中禁止使用下列模板：
序列：vector，list，deque
序列适配器：stack，queue，priority_queue
关联容器：map, multimap, set, multiset
拟容器：valarray
散列容器：hash_map, hash_set, hash_multimap, hash_multiset
所有的标准库算法。
与这些模板相关的下列头文件禁止出现在程序中：
<vector >
<list >
<deque >
<stack >
<map >
<set >
<algorithm>

http://www.noi.cn/newsview.html?id=67&hash=2DA1FD&type=6

No optimization toggle
http://www.noi.cn/newsview.html?id=559&hash=E4E249&type=11

- "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


- "It is not possible for std::error and ntstatus having a one-to-one mapping." My impression is that you're wrong about this. My understanding of the current vague ideas around std::error is that it would be like std::error_code — you could totally have a std::error in the NTSTATUS domain ("category"), whose payload ("code") is an arbitrary 32-bit integer.

That is the problem. That violates zero-overhead principle which means this will never work. 14ned’s implementation is definitely horrible.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Arthur O'Dwyer<mailto:arthur.j.odwyer_at_[hidden]>
Sent: Thursday, October 3, 2019 16:46
Subject: Re: [std-proposals] FW: Reply to Herb Sutter about Zero-Overhead deterministic. It is not true.

On Tue, Oct 1, 2019 at 4:59 PM sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>
> https://bitbucket.org/ejsvifq_mabmip/proposal/raw/a88e370134e31d5b6f084d686ba829b7f4627b2c/2215.pdf

Interesting. I'm generally sympathetic to your concerns about Herbceptions; I think they don't solve most of the problems they set out to. However, your paper
- is in drastic need of proofreading,
- reads as unnecessarily aggrieved,
- makes several wrong-sounding claims without citing evidence, and
- veers off into a poorly-thought-out counter-proposal in the last 4 pages.

For "proofreading": would you consider publishing the LaTeX source code and accepting pull requests? At least you should change all instances of "fragilize" and "fragilized" to the English words "fragment" and "fragmented".

For "tone": pull requests might also help with this, but basically I think what'll help the most is to organize and focus your arguments to avoid getting distracted by minor points (such as the `isspace` thing). I would even recommend that you cut the last 4 pages — or else cut the first 7 pages! One or the other is not relevant to your theme.

For "citations needed":
- "Sutter thinks exceptions and RTTI are the only two violators of the zero-overhead principle."
- "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.
- "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?
- "A lot of middle school algorithm competition like NOIP is banning containers or not enabling optimization toggle." Citation wanted.
- "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 is not possible for std::error and ntstatus having a one-to-one mapping." My impression is that you're wrong about this. My understanding of the current vague ideas around std::error is that it would be like std::error_code — you could totally have a std::error in the NTSTATUS domain ("category"), whose payload ("code") is an arbitrary 32-bit integer.

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?

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`?

> This paper will revise the old deprecating exception specification with new meaning.

What "new meaning" are you assigning to throw-specifications? On first reading, it looks like you mean to give them exactly the same meaning that they had in C++03. If programmers didn't use throw-specifications in C++03 — if programmers often dislike checked exceptions even in Java — why would programmers want to use them in future-C++?

Section 3.10, "auto noexcept", is the feature often known as "noexcept(auto)".
Please read https://quuxplusone.github.io/blog/2018/06/12/attribute-noexcept-verify/

HTH,
Arthur