Dear Shengdung Wang,   you have not answered some/most of the questions I have asked. Especially the most important question, what is the actual reason of the performance degradation of .at()?   This is your main argument to introduce a new member function.   You also state that you do not want debug output (regardless of performance), but that reason alone would surely not merit a new function.   So please go into detail, what causes the optimizer not to reorder code.   If you want to introduce a third alternative for accessing members, there should be enough motivation including understanding the drawbacks of the existing ways and there should be no alternative ways to achieve those goals with the existing options. Even improving the existing options (with changes to the standard or improving the optimizer) should not be sufficient.   [] does no bounds checking (according to the standard, some implementations do, or optionally do).   So you have to reason, why .at(), which does bounds checking, is not suitable. As stated, just the prevention of debug output on the console (if it had no performance impact on the hot code path without bounds violations) probably would not merit a standards change, as the debug output is implementation specific (for the compiler vendor) and could be better solved with a flag/define/... there.   Best, Sebastian     -----Ursprüngliche Nachricht----- Von:trtaab trtaab via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 06.07.2023 04:46 Betreff:Re: [std-proposals] Std-Proposals Digest, Vol 52, Issue 15 An:std-proposals_at_[hidden]; CC:trtaab trtaab <tvfvof_at_[hidden]>; Dear Sebastian,   Thank you for your response and for bringing up the topic of exception handling (EH). I appreciate the opportunity to further discuss this aspect and provide additional insights.   You are correct in highlighting that changing the behavior of EH does not directly address the need for controlled program termination in the case of bounds checking failures. Even if -fno-exceptions is not explicitly used in most programs, there are still scenarios where developers desire a crashing mechanism to handle bounds checking failures efficiently and ensure program integrity.   The proposal for the "silent_at" method aims to address this specific requirement by providing a separate interface for efficient bounds checking. By introducing this method, developers can achieve controlled program termination without relying on exceptions or modifying the behavior of EH mechanisms.   It is important to note that the proposal does not advocate for a replacement or alteration of EH mechanisms, as they serve valuable purposes in other aspects of C++ programming. Rather, it offers an additional option specifically tailored to bounds checking, allowing developers to choose the appropriate level of safety and efficiency based on their specific needs.   I appreciate your engagement in this discussion and the opportunity to provide further clarification. If you have any additional thoughts or concerns, please feel free to share them.   Thank you for your contributions to the ongoing development of the C++ language.   Best regards,   Sent from Mail for Windows   From: std-proposals-request_at_[hidden] <mailto:std-proposals-request_at_[hidden]> Sent: Wednesday, July 5, 2023 22:42 To: std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> Subject: Std-Proposals Digest, Vol 52, Issue 15   Send Std-Proposals mailing list submissions to         std-proposals_at_[hidden] To subscribe or unsubscribe via the World Wide Web, visit         https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals or, via email, send a message with subject or body 'help' to         std-proposals-request_at_[hidden] You can reach the person managing the list at         std-proposals-owner_at_[hidden] When replying, please edit your Subject line so it is more specific than "Re: Contents of Std-Proposals digest..." Today's Topics:    1. Re: Std-Proposals Digest, Vol 52, Issue 14 (trtaab trtaab) ---------------------------------------------------------------------- Message: 1 Date: Thu, 6 Jul 2023 02:41:46 +0000 From: trtaab trtaab <tvfvof_at_[hidden]> To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 52, Issue 14 Message-ID:         <DM4PR02MB90694E932D6AE616F1E66B7BC72CA_at_[hidden]>         Content-Type: text/plain; charset="us-ascii" Dear Thiago Macieira, Thank you for your response and additional points regarding the proposal for the "silent_at" method. I appreciate the opportunity to address your concerns. Please find my counterarguments below: The term "silent" in the context of the proposal refers to the absence of additional output from the standard library, such as error messages or debug information. While crashes are not inherently silent, the use of a reliable crash mechanism, whether it's __builtin_trap() or other similar methods, is intended to provide a controlled program termination without generating extraneous output. The primary focus is on achieving a clean crash without introducing additional noise or debug information. The inclusion of file and line information in error reporting during bounds checking is a common practice in many programming languages and can be a valuable tool for debugging. However, the absence of such information in the proposed "silent_at" method does not indicate a prioritization of performance over correctness. Instead, it is a deliberate design choice to cater to developers who prefer a minimalistic approach without any output or debugging information. This approach is particularly useful in scenarios where developers have already ascertained that the indexes cannot be out of bounds and wish to eliminate any unnecessary overhead. I hope this clarifies my perspective on the matter. Your insights have been valuable in shaping the ongoing discussion and refinement of the proposal. If you have any further thoughts or concerns, I would be more than happy to address them. Thank you for your engagement in this discussion. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]> Sent: Wednesday, July 5, 2023 22:34 To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> Subject: Std-Proposals Digest, Vol 52, Issue 14 Send Std-Proposals mailing list submissions to         std-proposals_at_[hidden] To subscribe or unsubscribe via the World Wide Web, visit         https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals or, via email, send a message with subject or body 'help' to         std-proposals-request_at_[hidden] You can reach the person managing the list at         std-proposals-owner_at_[hidden] When replying, please edit your Subject line so it is more specific than "Re: Contents of Std-Proposals digest..." Today's Topics:    1. Re: Efficient and silent bounds checking with silent_at()       (Jason McKesson)    2. Re: Efficient and silent bounds checking with silent_at()       (Thiago Macieira)    3. Re: Efficient and silent bounds checking with silent_at()       (Thiago Macieira)    4. Re: Efficient and silent bounds checking with silent_at()       (trtaab trtaab)    5. Re: Efficient and silent bounds checking with silent_at()       (Sebastian Wittmeier) ---------------------------------------------------------------------- Message: 1 Date: Wed, 5 Jul 2023 22:03:25 -0400 From: Jason McKesson <jmckesson_at_[hidden]> To: std-proposals_at_[hidden] Subject: Re: [std-proposals] Efficient and silent bounds checking with         silent_at() Message-ID:         <CANLtd3WxxvbV0yzfZR+_AiddjOCJ=YzVt74vPAioPVoifCH8Yg_at_[hidden]> Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2023 at 9:56?PM trtaab trtaab via Std-Proposals <std-proposals_at_[hidden]> wrote: > > Dear Jason McKesson, > > > > Thank you for your response and bringing up the topic of contracts. While the proposed "silent_at" method shares similarities with contracts in terms of enforcing bounds checking, there are some key distinctions to consider. > > > > Contracts, as currently implemented in the libstdc++ library, can be computationally expensive due to the additional overhead introduced by passing parameters to the contract violator and the use of exception throwing for the contract terminator. Furthermore, contracts may generate output, which can include additional debug information that some developers prefer to avoid. I don't know of the current state of contracts as a C++ language proposal, but the last time I looked into them, basically none of that existed. So I'm don't care overly much about something libstdc++ has done internally; if the actual language feature doesn't require any of that overhead, then bringing it up here is essentially a non-sequitur. ------------------------------ Message: 2 Date: Wed, 05 Jul 2023 19:08:42 -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: <23136868.6Emhk5qWAg_at_[hidden]> Content-Type: text/plain; charset="us-ascii" On Wednesday, 5 July 2023 18:56:37 PDT trtaab trtaab via Std-Proposals wrote: > silent crash without any output. By utilizing mechanisms such as > __builtin_trap() in GCC and Clang, the method offers a controlled program > termination without producing any additional garbage or debug output. Crashes are NOT silent. However, _exit is silent. Please change your function's name and provide a generic implementation for a compiler that doesn't implement __builtin_trap. Please also provide commentary on how developers would debug such faults, such as compiling in debug mode, or doing post-mortem debugging, even if the comment is "this is not debuggable". > This distinction is particularly important for developers who prioritize > performance and optimization, as well as those who prefer a minimalistic > approach without the overhead of exceptions or unwanted output. Those developers prioritise performance over correctness? And if those developers have already ascertained that the indexes cannot be out of bounds, would they need your suggested method at all? -- 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 *********************************************   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals