Date: Sat, 5 Oct 2019 01:39:16 -0400
>
> “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
> “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
Received on 2019-10-05 00:41:40