Date: Fri, 8 Mar 2024 16:56:01 +0200
I came up with this (quite ugly) implementation:
struct Vec3 {
union {
float my_vec[1];
float x;
};
float y;
float z;
};
This will probably be flagged by sanitizers and some compilers as unsafe,
but I believe it's standard-compliant and does what's asked for.
On Fri, Mar 8, 2024 at 2:53 PM Jens Maurer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> 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>
> >
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
struct Vec3 {
union {
float my_vec[1];
float x;
};
float y;
float z;
};
This will probably be flagged by sanitizers and some compilers as unsafe,
but I believe it's standard-compliant and does what's asked for.
On Fri, Mar 8, 2024 at 2:53 PM Jens Maurer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> 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>
> >
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Received on 2024-03-08 14:56:14