Date: Sun, 15 Dec 2024 00:40:13 +0200
> IDK Rust well, but AFAIK Rust Box works better than std::unique_ptr
because of Rust language borrow checking, not something you can fix by new
type in C++
Because Rust has move semantics defined in a way that consumes the object,
it inherently works better and C++ won't ever be able to reproduce this
without some major core changes which I can't even imagine.
> I believe proposal I linked(not related to it in any way personally)
gives us best emulation of never empty pointer we can get in
C++(considering weaker language tracking of references/pointers), if after
reading that proposal you still think your suggestion addresses some
usecase feel free to correct me, maybe I misunderstood you or proposal I
linked.
I did misread, allocations do not occur on moving, but implicit copies and
being able to be valueless are the main clashes that my ideal proposal
cannot have. The main purpose of it is still being a very tight smart
pointer, which means it should not have any allocation responsibilities,
only cleanup.
svētd., 2024. g. 15. dec., plkst. 00:03 — lietotājs Ivan Matek (<
libbooze_at_[hidden]>) rakstīja:
> On Sat, Dec 14, 2024 at 10:36 PM Oskars Putans <o.putaans_at_[hidden]>
> wrote:
>
>>
>> Of course. However if you have to both add and remove functionality,
>> those are grounds to make it a separate object.
>> As this is an even more strict unique_ptr, I would like to see it
>> implemented in the standard.
>> I believe more frequent usage of this could lead to safer code.
>>
>
> I generally agree that having something like this would be nice, but
>
> 1. IDK Rust well, but AFAIK Rust Box works better than
> std::unique_ptr because of Rust language borrow checking, not something you
> can fix by new type in C++
> 2. I believe proposal I linked(not related to it in any way
> personally) gives us best emulation of never empty pointer we can get in
> C++(considering weaker language tracking of references/pointers), if after
> reading that proposal you still think your suggestion addresses some
> usecase feel free to correct me, maybe I misunderstood you or proposal I
> linked.
>
>
because of Rust language borrow checking, not something you can fix by new
type in C++
Because Rust has move semantics defined in a way that consumes the object,
it inherently works better and C++ won't ever be able to reproduce this
without some major core changes which I can't even imagine.
> I believe proposal I linked(not related to it in any way personally)
gives us best emulation of never empty pointer we can get in
C++(considering weaker language tracking of references/pointers), if after
reading that proposal you still think your suggestion addresses some
usecase feel free to correct me, maybe I misunderstood you or proposal I
linked.
I did misread, allocations do not occur on moving, but implicit copies and
being able to be valueless are the main clashes that my ideal proposal
cannot have. The main purpose of it is still being a very tight smart
pointer, which means it should not have any allocation responsibilities,
only cleanup.
svētd., 2024. g. 15. dec., plkst. 00:03 — lietotājs Ivan Matek (<
libbooze_at_[hidden]>) rakstīja:
> On Sat, Dec 14, 2024 at 10:36 PM Oskars Putans <o.putaans_at_[hidden]>
> wrote:
>
>>
>> Of course. However if you have to both add and remove functionality,
>> those are grounds to make it a separate object.
>> As this is an even more strict unique_ptr, I would like to see it
>> implemented in the standard.
>> I believe more frequent usage of this could lead to safer code.
>>
>
> I generally agree that having something like this would be nice, but
>
> 1. IDK Rust well, but AFAIK Rust Box works better than
> std::unique_ptr because of Rust language borrow checking, not something you
> can fix by new type in C++
> 2. I believe proposal I linked(not related to it in any way
> personally) gives us best emulation of never empty pointer we can get in
> C++(considering weaker language tracking of references/pointers), if after
> reading that proposal you still think your suggestion addresses some
> usecase feel free to correct me, maybe I misunderstood you or proposal I
> linked.
>
>
Received on 2024-12-14 22:40:26