On Mon, Dec 12, 2022 at 03:05:03PM -0500, Jason C via Std-Proposals wrote:
> (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.)

unique_resource is in the section after scoped_... in library
fundamentals v3.

/MF

> 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
> >>>
> >>

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
Magnus Fromreide					+46-13 17 68 48
Tornhagsvägen 24, 2tr					magfr_at_[hidden]
SE-582 37  LINKÖPING