std-proposals

From: trtaab trtaab <tvfvof_at_[hidden]> · Date: Thu, 6 Jul 2023 02:46:23 +0000

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering
------------------------------
Message: 3
Date: Wed, 05 Jul 2023 19:20:27 -0700
From: Thiago Macieira <thiago_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Efficient and silent bounds checking with
        silent_at()
Message-ID: <1832734.atdPhlSkOF_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
On Wednesday, 5 July 2023 19:00:29 PDT trtaab trtaab via Std-Proposals wrote:
> Regarding the term "silent crash," I apologize for any confusion caused. By
> "silent," I meant the absence of any output through stdio, not to be
> confused with a complete absence of any indication of a crash. The
> intention is to avoid any additional output that may be generated by the
> standard library, such as error messages or debug information, while still
> terminating the program in a controlled manner.
Then don't use __builtin_trap, because the traps that it generates can be
caught (on Unix systems, by installing a handler for SIGABRT) and then produce
a non-silent output.
> In response to your suggestion of adding assertions to the operator[]
> method, I acknowledge the potential benefits it may offer. However, doing
> so could lead to One-Definition Rule (ODR) violations when multiple
> versions of the container, with and without assertions, are used within the
> same program. This could cause conflicts during linkage and introduce
> ambiguity in the behavior of the program.
That's a fair argument, though one that in reality (stepping outside of the
standard) only applies to debug-mode code, which is when you want this. It
does mean there's some value in having an extra method that does assertions
and keeps operator[] assertion-free.
However, that value is minimal and may be smaller than the cost of requiring a
single NDEBUG state. Compare that to the cost of modifying the source code to
use this new method.
I also posit that this would be useful as a debugging tool, but the extra
checks should be removed in release mode. This would require that either those
are assertions controlled by NDEBUG or similar mechanisms (thus creating the
ODR problem again) or that the developers would ned to call different functions
in debug vs release mode, which is not acceptable.
Maybe what we need is a refresh of assert() to require it not to be an ODR
violation in the first place. If it were replaced with a builtin of its own
  __builtin_assert(boolean_expr, message);
the compiler could decide to emit code or not emit code under its own control.
Furthermore, it could also use the expression in release mode as an
optimisation hint (__builtin_assume).
> The proposed silent_at method provides a separate interface that
> specifically addresses the need for efficient bounds checking while
> allowing developers to choose the appropriate level of safety for their use
> cases. By introducing a distinct method, we can ensure clarity,
> consistency, and compatibility across different implementations and use
> scenarios.
I think you need to explore the "allowing developers to choose" portion first.
You're basing your proposal on something that doesn't exist, but if it did it
wouldn't need your proposal in the first place. Moreover, that control could be
of great value in other places.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering
------------------------------
Message: 4
Date: Thu, 6 Jul 2023 02:30:44 +0000
From: trtaab trtaab <tvfvof_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Efficient and silent bounds checking with
        silent_at()
Message-ID:
        <DM4PR02MB9069EC0FBBC1AD646E4CAD47C72CA_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
Dear Thiago Macieira,
Thank you for your valuable input and perspectives on the proposal for the "silent_at" method. I appreciate the opportunity to engage in a meaningful discussion on this topic. I would like to address your points and provide a counterargument for further consideration:
The main objective of the "silent_at" method is to cater to individuals who prioritize specific safety requirements without incurring unnecessary costs. This approach aligns with the principle of "pay for what you use" and adheres to the zero-overhead principle. By avoiding the printing of information during bounds checking, the "silent_at" method aims to prevent any violations of the zero-overhead principle and ensures that users only incur the desired safety features without additional overhead.
Your argument regarding changing existing code with a new implementation raises an important concern. The presence of at() and operator[] already creates dialects in the codebase. However, it's worth noting that the widespread use of the -fno-exceptions flag in the C++ community prevents the utilization of the at() method altogether. This limitation further reinforces the need for an alternative method, such as "silent_at," that caters to users who cannot rely on exceptions in their codebase due to compile-time configurations.
I hope these points provide a compelling counterargument and further contribute to the discussion. I appreciate your perspectives and the opportunity to engage in a constructive dialogue on this topic.
If you have any additional thoughts or insights to share, please don't hesitate to let me know.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 5
Date: Thu, 6 Jul 2023 04:34:35 +0200
From: Sebastian Wittmeier <wittmeier_at_[hidden]>
To: std-proposals_at_[hidden]  <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Efficient and silent bounds checking with
        silent_at()
Message-ID:
        <zarafa.64a6283b.2059.7ab7f7ea7543e92f_at_lvps176-28-11-36.dedicated.hosteurope.>
Content-Type: text/plain; charset="utf-8"
Dear Shengdun Wang,
you are proposing a member function, which does bounds checking, but instead of throwing an exception, would be aborting the program.
?
You state, the optimizer can reorder instructions better this way.
?
Could you please clarify the reason for it? Is it, because no exceptions are thrown or because no output is made to the console?
Is it because of the specific implementation within libstdc++ or because of the standardized behavior of .at()?
Could this in theory also be solved with improvements to the optimizer?
?
The comparison to the upcoming (not current yet) contracts feature of C++ is important, as bounds-checking is a prime example for checking a pre-condition.
One would expect to get a good compromise between safety and performance for contracts, too.
Either the contracts proposal can learn from your findings to get it done the right way from the start and/or your proposal can be subsumed within the existing .at() configured by a suitable 'contracts configuration' without the need for introducing a new member function and being more compatible with existing code.
?
So it is very important, what the reason for the performance loss actually is, and what the minimum change for solving it is. E.g. can exceptions be kept, even if _you_ do not use them?
If exceptions are the absolute reason for the performance loss in this case, can they be implemented in a different way to prevent it?
There are also proposals to change the C++ exception mechanism with a simpler alternative, which is acceptable to a broader range of C++ programmers.
?
Best,
Sebastian
?
-----Urspr?ngliche Nachricht-----
Von:trtaab trtaab via Std-Proposals <std-proposals_at_[hidden]>
Gesendet:Do 06.07.2023 01:38
Betreff:[std-proposals] Efficient and silent bounds checking with silent_at()
An:std-proposals_at_[hidden];
CC:trtaab trtaab <tvfvof_at_[hidden]>;
Dear ISO C++ Committee,
?
I am writing to propose the addition of a new method, "reference silent_at(size_type index) noexcept," to all random access containers in C++. This proposal aims to address the concern of bounds checking in a manner that balances efficiency and safety.
?
To provide further clarity and support for this proposal, I would like to share some code references that demonstrate the proposed silent_at() method and its benefits.
?
By studying these code references, it becomes evident that the proposed silent_at() method can offer a pragmatic compromise between the unchecked operator[] and the exception-throwing at() methods. It enables efficient bounds checking while ensuring controlled program termination without producing any output.
?
I sincerely appreciate your consideration of this proposal and the opportunity to contribute to the ongoing development of the C++ language. I eagerly await your feedback and the possibility of engaging in further discussions regarding this idea.
?
Thank you for your time and attention.
?
References:
silent_at:
https://godbolt.org/z/4v7Eo3ce9
?
at with supposed implementation:
https://godbolt.org/z/soK98Prjh
?
libstdc++ with _GLIBCXX_ASSERTIONS :
https://godbolt.org/z/vWzsxshGv
?
Rust Inefficiency due to too much debugging output:
https://godbolt.org/z/M455GqsE6
?
?
Sincerely,
?
Shengdun Wang
tvfvof_at_[hidden]
?
Sent from Mail for Windows
?
--
 Std-Proposals mailing list
 Std-Proposals_at_[hidden]
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
End of Std-Proposals Digest, Vol 52, Issue 14
*********************************************
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
End of Std-Proposals Digest, Vol 52, Issue 15
*********************************************