Date: Tue, 1 Feb 2022 19:01:21 +0100
P1029 + operator reloc would not enforce either callee- nor caller-cleanup.
Compilers can still use whatever they use now, and marking constructor
as bitcoping is just an optimization hint for the compiler that the
destruction of moved-from object is no-op.
Of course for callee-cleanup it is much easier to optimize such no-op
moved-from object destructor, but it should be possible for
caller-cleanup scenarios as well (even for cross-TU calls if
interprocedural analysis can verify, that in all possible paths of
execution of callee function the passed-by-value object is relocated
further).
Regards,
Maciej
wt., 1 lut 2022 o 18:37 Gašper Ažman via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> For anyone considering callee-cleanup to be a desirable direction, please know that the general thought is more towards caller-cleanup and that callee-cleanup was a mistake.
>
> There are disagreements on the issue, but I don't think any feature that would end up mandating either of those will pass the committee. We're having similar issues with contracts (albeit there, we're having issues only on callee-cleanup arches).
>
> On Tue, Feb 1, 2022 at 5:31 PM Bjorn Reese via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Just adding another failed attempt to the fray.
>>
>> I explored another venue that uses stateful metaprogramming to enable or
>> disable member functions. The basic idea was to use constrain member
>> functions on compile-time counters. A ultimate goal was to disable
>> destructors if their "destructive move constructor/function" had been
>> called.
>>
>> Unfortunately that did not work out because metaprogramming is not aware
>> of control flow, so enabling or disabling member function did not work
>> correctly with conditional statements or loops.
>>
>> http://breese.github.io/2021/06/06/almost-affine.html
>> http://breese.github.io/2021/06/13/obscurable-types.html
>> --
>> 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
Compilers can still use whatever they use now, and marking constructor
as bitcoping is just an optimization hint for the compiler that the
destruction of moved-from object is no-op.
Of course for callee-cleanup it is much easier to optimize such no-op
moved-from object destructor, but it should be possible for
caller-cleanup scenarios as well (even for cross-TU calls if
interprocedural analysis can verify, that in all possible paths of
execution of callee function the passed-by-value object is relocated
further).
Regards,
Maciej
wt., 1 lut 2022 o 18:37 Gašper Ažman via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> For anyone considering callee-cleanup to be a desirable direction, please know that the general thought is more towards caller-cleanup and that callee-cleanup was a mistake.
>
> There are disagreements on the issue, but I don't think any feature that would end up mandating either of those will pass the committee. We're having similar issues with contracts (albeit there, we're having issues only on callee-cleanup arches).
>
> On Tue, Feb 1, 2022 at 5:31 PM Bjorn Reese via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Just adding another failed attempt to the fray.
>>
>> I explored another venue that uses stateful metaprogramming to enable or
>> disable member functions. The basic idea was to use constrain member
>> functions on compile-time counters. A ultimate goal was to disable
>> destructors if their "destructive move constructor/function" had been
>> called.
>>
>> Unfortunately that did not work out because metaprogramming is not aware
>> of control flow, so enabling or disabling member function did not work
>> correctly with conditional statements or loops.
>>
>> http://breese.github.io/2021/06/06/almost-affine.html
>> http://breese.github.io/2021/06/13/obscurable-types.html
>> --
>> 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
Received on 2022-02-01 18:01:35