On Tue, 11 Mar 2025 at 23:11, Brian Bi <bbi5291@gmail.com> wrote:

On Tue, Mar 11, 2025 at 10:04 AM Yongwei Wu via Std-Discussion <std-discussion@lists.isocpp.org> wrote:

On Mon, 10 Mar 2025 at 17:36, Giuseppe D'Angelo via Std-Discussion
<std-discussion@lists.isocpp.org> wrote:
>
> On 25/02/2025 12:45, Yongwei Wu via Std-Discussion wrote:
> > Currently, Obj::scratch_buffer will contain indeterminate values. In
> > C++26, will there be a way for it to opt out of the erroneous value
> > initialization, sans requiring the user to change the client-side
> > code?
>
> I think there's a misunderstanding here: EB doesn't mandate that the
> storage for an automatic variable gets initialized in any specific way.
> It just changes the semantics of what happens if you read from an
> uninitialized automatic variable (you get EB). The [[indeterminate]]
> attribute restores the pre-C++26 semantics (you get UB).

The problem is not the avoidance of UB, but the potential harm to
performance. And I do not want the user to use the [[indeterminate]]
attribute, which is awkward and simply wrong in semantics.

> Do you have a use case for always wanting UB instead of EB for
> uninitialized reads of a non-static data member?

Was my example not good enough? OK, a more real one. But keep in mind
I do not want UB, just that I do not want the compiler to initialize
some uninitialized data members.

I wrote a BigFixedString for test purposes, and google-benchmarked it.
Two versions are posted online:

https://quick-bench.com/q/9QkL9cSkqHSi2pb5A-TTkglbaDU
https://quick-bench.com/q/MmE9IwFaXqjz_gFnEmSK8s3qFrA

The difference is that one has a member `char buffer_[128];`, and the
other `char buffer_[128]{};`. Of course, the uninitialized data are
never read.

Currently the benchmark results show the performance difference is
about 90:54. Always initializing seems to have a 65% penalty on
performance.

I'm uncomfortable with the idea of a class author being able to override the user's choice to not declare a local variable [[indeterminate]], by placing [[indeterminate]] on the declaration of a non-static data member and thus making part of the object's storage indeterminate anyway. Note that even if it's just in a private member, there will still be UB if the object is used as the source of `memcpy`.

When a user writes `[[indeterminate]]`, it is their intention to exploit the potential efficiency of not initializing certain storage. When I, as class author, write `[[indeterminate]]` on data members, it is my intention (and responsibility) to exploit the efficiency and make sure I do not make mistakes.

If a reasonable use of my code requires users to write `[[indeterminate]]`, it is an overburden for users. If they are cautious, they will have to check the implementation details of my class, which defeats the purpose of encapsulation.