Date: Fri, 28 Jun 2024 19:50:36 +0300
I did not follow the emails but isnt this the same as move c-tor? It can
also be used to reallocate the object to new address.
On Fri, Jun 28, 2024, 19:43 F. v.S. via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I totally disagree on that this can be an easy and flexible way. But I'd
> hear what other guys say.
>
> It seems to me that when the new relocating "destructor" is not defaulted,
> the identity (or the address) of the returned object (i.e. the destination
> of relocation) ALMOST ALWAYS needs to be known in the function body. So
> it'll be simpler, at least to me, to invent a new way to directly refer to
> the destination object, instead of finding how to guarantee NRVO.
>
> Thanks,
> F.v.S.
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of 李 秋逸 via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Saturday, June 29, 2024 0:31
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* 李 秋逸 <QiuyiLi1023_at_[hidden]>
> *Subject:* [std-proposals] Relocating destructor and operator reloc
>
> Sorry for bother you. Seeing some proposals about relocating in C++, I
> think I found a easy and flexible way to do this with least changes to the
> core feature of C++ language. You can check it in the attachment or click *https://github.com/YandereChan2/Relocating-destructor-and-operator-reloc/blob/main/Operator%20reloc%20and%20relocating%20destructor.md
> <https://github.com/YandereChan2/Relocating-destructor-and-operator-reloc/blob/main/Operator%20reloc%20and%20relocating%20destructor.md>*
> .
>
> The core idea is introduce a new destructor T ~T(int), and with the help
> of RVO/NRVO to relocate an object from one address to the address of the
> return value.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
also be used to reallocate the object to new address.
On Fri, Jun 28, 2024, 19:43 F. v.S. via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I totally disagree on that this can be an easy and flexible way. But I'd
> hear what other guys say.
>
> It seems to me that when the new relocating "destructor" is not defaulted,
> the identity (or the address) of the returned object (i.e. the destination
> of relocation) ALMOST ALWAYS needs to be known in the function body. So
> it'll be simpler, at least to me, to invent a new way to directly refer to
> the destination object, instead of finding how to guarantee NRVO.
>
> Thanks,
> F.v.S.
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of 李 秋逸 via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Saturday, June 29, 2024 0:31
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* 李 秋逸 <QiuyiLi1023_at_[hidden]>
> *Subject:* [std-proposals] Relocating destructor and operator reloc
>
> Sorry for bother you. Seeing some proposals about relocating in C++, I
> think I found a easy and flexible way to do this with least changes to the
> core feature of C++ language. You can check it in the attachment or click *https://github.com/YandereChan2/Relocating-destructor-and-operator-reloc/blob/main/Operator%20reloc%20and%20relocating%20destructor.md
> <https://github.com/YandereChan2/Relocating-destructor-and-operator-reloc/blob/main/Operator%20reloc%20and%20relocating%20destructor.md>*
> .
>
> The core idea is introduce a new destructor T ~T(int), and with the help
> of RVO/NRVO to relocate an object from one address to the address of the
> return value.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-06-28 16:50:52