Date: Thu, 13 Mar 2025 11:00:07 +0100
On 13/03/2025 05.16, Yongwei Wu via Std-Discussion wrote:
> On Wed, 12 Mar 2025 at 10:46, Yongwei Wu <wuyongwei_at_[hidden] <mailto:wuyongwei_at_[hidden]>> wrote:
>
> On Tue, 11 Mar 2025 at 23:11, Brian Bi <bbi5291_at_[hidden] <mailto:bbi5291_at_[hidden]>> wrote:
> 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`.
"memcpy" only works for trivially copyable types to start with
[basic.types.general] p2+p3.
But it does work on indeterminate bytes, and faithfully copies those
to the destination.
For classes that have byte buffers or "scratch space", I would expect
that the class author ensures they can't be copied, or, if the scratch
space happens to contain an object, that object is copied as appropriate,
instead of relying on the default copy constructor. Thus, the class
isn't trivially copyable anyway, and thus "memcpy" doesn't apply.
> 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.
[[indeterminate]] can't appear on data members at this time:
[dcl.attr.indet] p1.
Jens
> 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.
>
>
> Furthermore, I have the concern that erroneous behaviour, as it is currently specified, may hinder the adoption of C++26, as it may slow down certain applications, */without a proper way of remedy/*. No, adding the [[indeterminate]] attribute to class-type local objects is not a remedy, but uglification. It is far too confusing to mark a class-type object with proper constructors as [[indeterminate]].
>
> I personally think it should be addressed in a new proposal, or maybe a revised P2795? Opinions?
>
> --
> Yongwei Wu
> URL: http://wyw.dcweb.cn/ <http://wyw.dcweb.cn/>
>
> On Wed, 12 Mar 2025 at 10:46, Yongwei Wu <wuyongwei_at_[hidden] <mailto:wuyongwei_at_[hidden]>> wrote:
>
> On Tue, 11 Mar 2025 at 23:11, Brian Bi <bbi5291_at_[hidden] <mailto:bbi5291_at_[hidden]>> wrote:
> 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`.
"memcpy" only works for trivially copyable types to start with
[basic.types.general] p2+p3.
But it does work on indeterminate bytes, and faithfully copies those
to the destination.
For classes that have byte buffers or "scratch space", I would expect
that the class author ensures they can't be copied, or, if the scratch
space happens to contain an object, that object is copied as appropriate,
instead of relying on the default copy constructor. Thus, the class
isn't trivially copyable anyway, and thus "memcpy" doesn't apply.
> 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.
[[indeterminate]] can't appear on data members at this time:
[dcl.attr.indet] p1.
Jens
> 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.
>
>
> Furthermore, I have the concern that erroneous behaviour, as it is currently specified, may hinder the adoption of C++26, as it may slow down certain applications, */without a proper way of remedy/*. No, adding the [[indeterminate]] attribute to class-type local objects is not a remedy, but uglification. It is far too confusing to mark a class-type object with proper constructors as [[indeterminate]].
>
> I personally think it should be addressed in a new proposal, or maybe a revised P2795? Opinions?
>
> --
> Yongwei Wu
> URL: http://wyw.dcweb.cn/ <http://wyw.dcweb.cn/>
>
Received on 2025-03-13 10:00:15