Date: Fri, 5 Nov 2021 21:19:58 -0400
On Fri, Nov 5, 2021 at 9:17 PM language.lawyer--- via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 06/11/2021 03:42, Michael Scire via Std-Proposals wrote:
> > Is that to suggest the whole proposal is a no-go, then?
>
> No. To suggest that implementing something like parent_of_member in
> «conforming C++» would require more changes than P1839R2 introduces.
> It is a question to compiler developers: how much they rely on the fact
> that one can't, in general, go from a member subobject to its containing
> object and if they do, do they want to stop relying on this.
>
I don't think compiler developers rely on it at all, because people
currently write code like this, and compiler developers don't want to break
that code.
After all, it wasn't UB in C++14, and most people don't know that it
suddenly became UB in C++17.
>
> > I'm not sure -- it seems okay to me if there's no user-writable way to
> > perform such offsetof arithmetic, if there's a compiler-magic way to do
> the
> > pointer-of-member I'm interested in.
> >
> > Certainly I think that parent of member is a pretty useful operation at
> > runtime that it would be nice to be able to write without UB.
> >
> > On Fri, Nov 5, 2021 at 5:35 PM language.lawyer--- via Std-Proposals <
> > std-proposals_at_[hidden]> wrote:
> >
> >> On 06/11/2021 03:12, Brian Bi via Std-Proposals wrote:
> >>> `reinterpret_cast<uintptr_t>(std::addressof(reinterpret_cast<ParentType
> >>> *>(0)->*member_ptr))` is UB. You have to use the magic `offsetof`
> macro.
> >>> P1278 <http://wg21.link/p1278> proposes to add a similar non-macro
> >> facility.
> >>>
> >>> The problem is how to then perform the pointer arithmetic and convert
> the
> >>> result into a pointer to the parent type. This cannot be done in user
> >> code
> >>> in C++17, so even at runtime, it would require compiler magic. If P1839
> >>> <http://wg21.link/P1839> gets accepted, it will be possible to
> >> implement it
> >>> in user code.
> >>
> >> I think this has already been discussed in this mail list: it won't be
> >> possible.
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> 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
>
std-proposals_at_[hidden]> wrote:
> On 06/11/2021 03:42, Michael Scire via Std-Proposals wrote:
> > Is that to suggest the whole proposal is a no-go, then?
>
> No. To suggest that implementing something like parent_of_member in
> «conforming C++» would require more changes than P1839R2 introduces.
> It is a question to compiler developers: how much they rely on the fact
> that one can't, in general, go from a member subobject to its containing
> object and if they do, do they want to stop relying on this.
>
I don't think compiler developers rely on it at all, because people
currently write code like this, and compiler developers don't want to break
that code.
After all, it wasn't UB in C++14, and most people don't know that it
suddenly became UB in C++17.
>
> > I'm not sure -- it seems okay to me if there's no user-writable way to
> > perform such offsetof arithmetic, if there's a compiler-magic way to do
> the
> > pointer-of-member I'm interested in.
> >
> > Certainly I think that parent of member is a pretty useful operation at
> > runtime that it would be nice to be able to write without UB.
> >
> > On Fri, Nov 5, 2021 at 5:35 PM language.lawyer--- via Std-Proposals <
> > std-proposals_at_[hidden]> wrote:
> >
> >> On 06/11/2021 03:12, Brian Bi via Std-Proposals wrote:
> >>> `reinterpret_cast<uintptr_t>(std::addressof(reinterpret_cast<ParentType
> >>> *>(0)->*member_ptr))` is UB. You have to use the magic `offsetof`
> macro.
> >>> P1278 <http://wg21.link/p1278> proposes to add a similar non-macro
> >> facility.
> >>>
> >>> The problem is how to then perform the pointer arithmetic and convert
> the
> >>> result into a pointer to the parent type. This cannot be done in user
> >> code
> >>> in C++17, so even at runtime, it would require compiler magic. If P1839
> >>> <http://wg21.link/P1839> gets accepted, it will be possible to
> >> implement it
> >>> in user code.
> >>
> >> I think this has already been discussed in this mail list: it won't be
> >> possible.
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> 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
>
-- *Brian Bi*
Received on 2021-11-05 20:20:15