Date: Fri, 8 Mar 2024 13:53:31 +0100
On 08/03/2024 00.23, veronica alphonso via Std-Proposals wrote:
> The issue i see about making anonymous structs/classes standard, is that now something as confusing as this could be allowed:
>
> // on the global namespace...
> struct
> {
> int x;
> };
>
> void foo()
> {
> .x = 42;
> // what? so x is some kind of weird SDM/global now?
What is "SDM"?
> // what is its lifetime?
> }
We already have anonymous unions, suitably restricted to being
members of classes only.
Given those restrictions, how much of the problem space would
anonymous structs address?
Jens
> El jue, 7 mar 2024 a las 23:17, Sebastian Wittmeier via Std-Proposals (<std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>) escribió:
>
> __
>
> Dear Veronica,
>
> what about your mentioned alternative of anonymous unions and structs?
>
> They could be made standard-compliant.
>
> And would need less language changes.
>
>
>
> Would they have problems with UB due to which element is the active one? When used in your use case?
>
>
>
> Best regards,
>
> Sebastian
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* veronica alphonso via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> *Gesendet:* Do 07.03.2024 23:55
> *Betreff:* [std-proposals] Subscript aliasing
> *An:* std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>;
> *CC:* veronica alphonso <verodeving_at_[hidden] <mailto:verodeving_at_[hidden]>>;
> In C++ there isn't a standard-compliant way of creating named aliases of c-like array elements. In certain contexts, it is preferred to access these these array elements with a named identifier that is bounded to that particular array entry, e.g:
>
> union
> {
> float my_vec[3];
> struct
> {
> float x, y, z;
> };
> };
>
> However, anonymous structs/classes are only
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> The issue i see about making anonymous structs/classes standard, is that now something as confusing as this could be allowed:
>
> // on the global namespace...
> struct
> {
> int x;
> };
>
> void foo()
> {
> .x = 42;
> // what? so x is some kind of weird SDM/global now?
What is "SDM"?
> // what is its lifetime?
> }
We already have anonymous unions, suitably restricted to being
members of classes only.
Given those restrictions, how much of the problem space would
anonymous structs address?
Jens
> El jue, 7 mar 2024 a las 23:17, Sebastian Wittmeier via Std-Proposals (<std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>) escribió:
>
> __
>
> Dear Veronica,
>
> what about your mentioned alternative of anonymous unions and structs?
>
> They could be made standard-compliant.
>
> And would need less language changes.
>
>
>
> Would they have problems with UB due to which element is the active one? When used in your use case?
>
>
>
> Best regards,
>
> Sebastian
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* veronica alphonso via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> *Gesendet:* Do 07.03.2024 23:55
> *Betreff:* [std-proposals] Subscript aliasing
> *An:* std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>;
> *CC:* veronica alphonso <verodeving_at_[hidden] <mailto:verodeving_at_[hidden]>>;
> In C++ there isn't a standard-compliant way of creating named aliases of c-like array elements. In certain contexts, it is preferred to access these these array elements with a named identifier that is bounded to that particular array entry, e.g:
>
> union
> {
> float my_vec[3];
> struct
> {
> float x, y, z;
> };
> };
>
> However, anonymous structs/classes are only
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
Received on 2024-03-08 12:53:36