Date: Mon, 12 Dec 2022 15:05:03 -0500
(And to be honest, I'd much rather see a unique_ptr equivalent that
accepted non-pointer types rather than a general-purpose scoped cleanup
feature, since that would much more directly address the issue, in a
slightly less messy way.)
On Mon, Dec 12, 2022 at 3:02 PM Jason C <jason.cipriani_at_[hidden]> wrote:
> > What does `std:unique_ptr` add is not "already trivially possible"?
>
> Speaking of which, in the special case where your `Handle` in your
> original example is a pointer type, you can also use `std::unique_ptr` to
> wrap a `Handle` as another strategy, supplying FreeResource as the custom
> deleter, e.g. if `Handle` were a `void*`:
>
> unique_ptr<void,void(*)(Handle)> h(GetResource("monkey"),
> ReleaseResource);
>
> Not an appropriate strategy if your Handle is some other type, but useful
> in certain situations.
>
> Jason
>
>
>
> On Mon, Dec 12, 2022 at 2:46 PM Jason C <jason.cipriani_at_[hidden]> wrote:
>
>> > What does `std:unique_ptr` add is not "already trivially possible"?
>>
>> On its own it does not add much. With its counterparts `shared_ptr` and
>> `weak_ptr`, however, it adds a few things, such as interoperability with
>> `shared_ptr` e.g. via `make_unique`, etc.
>>
>> > Why does everyone need to roll their own "generic_cleanup" class when
>> there could be a simple standard-defined one?
>>
>> Two reasons, I think:
>> 1. There are a lot of ways to do it and the chosen strategy often depends
>> on context, code structure, etc.
>> 2. It's quick and easy to do so.
>>
>> > And yours is horribly inefficient, as it uses `std::function`.
>>
>> There's nothing inherently inefficient about std::function, although if
>> you prefer you can substitute `void (* cleanup)` as a pointer type, the
>> idea is identical and the actual implementation of any scope-based cleanup
>> code would end up yielding similar, if not identical, results. If it's
>> performance-critical cleanup code you should probably roll your own
>> anyways, or change resource management strategies in general, but I was
>> just trying to give constructive suggestions, take them or leave them. :)
>>
>> Jason
>>
>>
>> On Mon, Dec 12, 2022 at 1:27 PM Jason McKesson via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Mon, Dec 12, 2022 at 1:11 PM Jason C via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>> >
>>> > It is unclear to me what these proposals (both this new one and the
>>> `scope_*` proposals) add that is not already trivially possible with code
>>> in scoped object destructors.
>>>
>>> What does `std:unique_ptr` add is not "already trivially possible"? It
>>> adds vocabulary, so that everyone can easily see and digest what your
>>> intent is.
>>>
>>> Why does everyone need to roll their own "generic_cleanup" class when
>>> there could be a simple standard-defined one? And yours is horribly
>>> inefficient, as it uses `std::function`.
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
accepted non-pointer types rather than a general-purpose scoped cleanup
feature, since that would much more directly address the issue, in a
slightly less messy way.)
On Mon, Dec 12, 2022 at 3:02 PM Jason C <jason.cipriani_at_[hidden]> wrote:
> > What does `std:unique_ptr` add is not "already trivially possible"?
>
> Speaking of which, in the special case where your `Handle` in your
> original example is a pointer type, you can also use `std::unique_ptr` to
> wrap a `Handle` as another strategy, supplying FreeResource as the custom
> deleter, e.g. if `Handle` were a `void*`:
>
> unique_ptr<void,void(*)(Handle)> h(GetResource("monkey"),
> ReleaseResource);
>
> Not an appropriate strategy if your Handle is some other type, but useful
> in certain situations.
>
> Jason
>
>
>
> On Mon, Dec 12, 2022 at 2:46 PM Jason C <jason.cipriani_at_[hidden]> wrote:
>
>> > What does `std:unique_ptr` add is not "already trivially possible"?
>>
>> On its own it does not add much. With its counterparts `shared_ptr` and
>> `weak_ptr`, however, it adds a few things, such as interoperability with
>> `shared_ptr` e.g. via `make_unique`, etc.
>>
>> > Why does everyone need to roll their own "generic_cleanup" class when
>> there could be a simple standard-defined one?
>>
>> Two reasons, I think:
>> 1. There are a lot of ways to do it and the chosen strategy often depends
>> on context, code structure, etc.
>> 2. It's quick and easy to do so.
>>
>> > And yours is horribly inefficient, as it uses `std::function`.
>>
>> There's nothing inherently inefficient about std::function, although if
>> you prefer you can substitute `void (* cleanup)` as a pointer type, the
>> idea is identical and the actual implementation of any scope-based cleanup
>> code would end up yielding similar, if not identical, results. If it's
>> performance-critical cleanup code you should probably roll your own
>> anyways, or change resource management strategies in general, but I was
>> just trying to give constructive suggestions, take them or leave them. :)
>>
>> Jason
>>
>>
>> On Mon, Dec 12, 2022 at 1:27 PM Jason McKesson via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Mon, Dec 12, 2022 at 1:11 PM Jason C via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>> >
>>> > It is unclear to me what these proposals (both this new one and the
>>> `scope_*` proposals) add that is not already trivially possible with code
>>> in scoped object destructors.
>>>
>>> What does `std:unique_ptr` add is not "already trivially possible"? It
>>> adds vocabulary, so that everyone can easily see and digest what your
>>> intent is.
>>>
>>> Why does everyone need to roll their own "generic_cleanup" class when
>>> there could be a simple standard-defined one? And yours is horribly
>>> inefficient, as it uses `std::function`.
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
Received on 2022-12-12 20:05:30