C++ Logo


Advanced search

Re: [isocpp-lib] std::function

From: Marco Foco <mfoco_at_[hidden]>
Date: Fri, 14 Oct 2022 13:33:30 +0000
Out of curiosity, would some of the use cases for gaming/realtime applications be covered by P0792 (function_ref)?


From: SG14 <sg14-bounces_at_[hidden]> On Behalf Of Edward Catmur via SG14
Sent: Friday, 7 October 2022 21:11
To: sg14_at_[hidden]
Cc: Edward Catmur <ecatmur_at_[hidden]>; lib_at_[hidden]; Mathias Stearn <redbeard0531+isocpp_at_[hidden]>; Jonathan Wakely <cxx_at_[hidden]>
Subject: Re: [SG14] [isocpp-lib] std::function

External email: Use caution opening links or attachments

On Fri, 7 Oct 2022 at 16:57, Arthur O'Dwyer via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
On Tue, Oct 4, 2022 at 9:19 PM Patrice Roy via Lib <lib_at_[hidden]<mailto:lib_at_[hidden]>> wrote:
Le mar. 4 oct. 2022 à 17:47, Jonathan Wakely <cxx_at_[hidden]<mailto:cxx_at_[hidden]>> a écrit :
On Tue, 4 Oct 2022 at 20:53, Barath Kannan <barathwaj.kannan_at_[hidden]<mailto:barathwaj.kannan_at_[hidden]>> wrote:

Which is why I'm inclined to agree with Arthur that people should just write their own erasure abstractions (and if possible, the standard should try to offer tools to make this easier) rather than standardising things like inplace_function and any_invocable.

Agreed. std::function doesn't work well for everybody, but neither will whatever else we come up with. The standard library can't cover every use case.

I understand that.
The SG14 requests we are discussing these days form a somehow coherent whole, which I hope to turn into a somewhat coherent set of papers (not a request for ponies, hopefully). It might take a couple of meetings for us to decide the extent of this set of papers.
The aforementioned inplace_function<T,Sz> would be part of that [...]

I'd be interested to hear (perhaps off-list) whether anyone is actually using
as a third-party (or vendored) dependency in real life. The first criterion for "should it be in the standard" is always "are people already wanting to use it," and so far I haven't seen clear evidence (in the form of bug reports, feature requests, etc.) that anyone is actually using these things as they exist today.

Not exactly. Our non-allocating type-erasing function is trivial (and requires the function object it contains to be trivial, obviously). The thing is, if you allow type-erased move there's nothing stopping people putting an unique_ptr (or indirect_value, if it needs to be copyable) in there. Once you're paying for a vtable ptr, you may as well allow expanding into allocated memory; it's basically zero extra cost.

That said, as the it's useful to know (and static_assert) that construction won't allocate, but you can do that with a noexcept constrained ctor, allowing the user to check is_nothrow_constructible or noexcept(function(obj)). Or perhaps we could add a tagged (with std::in_place_t, if that isn't too precious?) ctor or static factory method to only accept non-allocating candidates.

Received on 2022-10-14 13:33:33