Date: Sat, 28 Dec 2024 01:23:29 +0300
Okay, that was to be expected. As I said, my dynamic array sometimes can't
handle things that std::vector can. It's simpler, so most likely the logic
from there will be incompatible with std::vector's logic. But anyway,
thanks for your answer.
Сб, 28 дек. 2024 г. в 01:14, Ivan Lazaric via Std-Proposals <
std-proposals_at_[hidden]>:
> > ... - and the fact that you can destructively move from a mutable
> reference in a called function is a footgun for the actual owner of the
> object which will still call the constructor.
>
> You can also just destroy the object via a mutable reference, I don't see
> this argument as that strong, we would just need to treat
> destructive move with same care as obj.~Class() .
>
>
> On Fri, Dec 27, 2024 at 1:31 PM Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Friday 27 December 2024 08:30:31 Brasilia Standard Time Oskars Putans
>> via
>> Std-Proposals wrote:
>> > My proposal isn't meant to solve these issues. It is merely a step in
>> that
>> > direction. What i'm proposing is an optional specialization for handling
>> > prvalues in a way that doesn't require the moved from value to be in a
>> > valid state.
>>
>> How does it mesh with the current object relocation proposals?
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel DCAI Platform & System Engineering
>>
>>
>>
>> --
>> 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
>
handle things that std::vector can. It's simpler, so most likely the logic
from there will be incompatible with std::vector's logic. But anyway,
thanks for your answer.
Сб, 28 дек. 2024 г. в 01:14, Ivan Lazaric via Std-Proposals <
std-proposals_at_[hidden]>:
> > ... - and the fact that you can destructively move from a mutable
> reference in a called function is a footgun for the actual owner of the
> object which will still call the constructor.
>
> You can also just destroy the object via a mutable reference, I don't see
> this argument as that strong, we would just need to treat
> destructive move with same care as obj.~Class() .
>
>
> On Fri, Dec 27, 2024 at 1:31 PM Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Friday 27 December 2024 08:30:31 Brasilia Standard Time Oskars Putans
>> via
>> Std-Proposals wrote:
>> > My proposal isn't meant to solve these issues. It is merely a step in
>> that
>> > direction. What i'm proposing is an optional specialization for handling
>> > prvalues in a way that doesn't require the moved from value to be in a
>> > valid state.
>>
>> How does it mesh with the current object relocation proposals?
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel DCAI Platform & System Engineering
>>
>>
>>
>> --
>> 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 2024-12-27 22:23:42