Yeah, floated the idea of exposing the size at which SBO threshold is set (through traits or something similar) thinking this would do the job (people could use std::function on their own function objects and static_assert on that object's size begin sufficiently small), but this did not get much traction yet; there seems to be more appetite (if I read SG14's wishes well) for a never-allocating cousin of std::function, at least so far... Discussions on this topic are not closed yet, so we'll see.
_______________________________________________Le lun. 3 oct. 2022 à 12:40, Ben Craig <ben.craig@ni.com> a écrit :Are there any examples of implementations that cause allocations, syscalls, or non-deterministic behavior for std::function when it is used with a function pointer, stateless lambda, or std::reference_wrapper? Is that std::function implementation claiming to be standards conforming?
Best I can tell, std::function is already specified to meet these requirements as best as can be done with the current specification techniques.
My suspicion is that the reluctance to use std::function is based off of some combination of general STL fear, and possibly some other requirements (e.g. user controllable small buffer optimization (SBO) instead of implementation tuned SBO).
From: Lib <lib-bounces@lists.isocpp.org> On Behalf Of Björn Andersson via Lib
Sent: Monday, October 3, 2022 11:58 AM
To: sg14@lists.isocpp.org
Cc: Björn Andersson <bjorn.andersson@ictech.se>; lib@lists.isocpp.org; Patrice Roy <patricer@gmail.com>
Subject: [EXTERNAL] Re: [isocpp-lib] [SG14] std::function
Den ons 21 sep. 2022 kl 03:07 skrev Patrice Roy via SG14 <sg14@lists.isocpp.org>:
Indeed, this type is part of a set of requests SG14 is working on these days.
The problem (for low-latency people) is that there's no programmatic way to know, in user code, if a given std::function instantiation will or will not allocate, so that makes this type unusable for some use cases (in particular, many game development companies will not touch std:function precisely for this reason; they don't just need an optimization, they need a guarantee).
Incidentally, this is exactly what the safety-critical people need as well: Not just the performance, but the guarantee of no syscall/deterministic behaviour.
Thanks,
Björn
Cheers!
Le mar. 20 sept. 2022 à 12:19, Arthur O'Dwyer via Lib <lib@lists.isocpp.org> a écrit :
On Tue, Sep 20, 2022 at 9:22 AM Bjarne Stroustrup via Lib <lib@lists.isocpp.org> wrote:
I thought we had a variant of std::function that didn't allocate on free
store for simple functions; it didn't make it for C++20? Is it still in
process? and if so where would I look for the current state of the proposal.
[cc: SG14]
SG14 has implemented, and I maintain, a type-erased `stdext::inplace_function<void(), Capacity, Align>` based on an informal proposal by Carl Cook in 2016:
It has never had a P-numbered proposal, and the area hasn't seen any movement that I'm aware of since circa 2018.
https://github.com/WG21-SG14/SG14/issues/125 inspired the implicit-move changes in C++20 (P1155 More Implicit Move).
https://github.com/WG21-SG14/SG14/issues/150 is still an important practical issue, where I happen to believe that the STL has chosen the wrong default as usual, and why I stopped caring much about the introduction of new type-erased types into the STL and started evangelizing type erasure as a technique so that people can just write their own.
HTH,
Arthur
_______________________________________________
Lib mailing list
Lib@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
Link to this post: http://lists.isocpp.org/lib/2022/09/23737.php_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
INTERNAL - NI CONFIDENTIAL
Lib mailing list
Lib@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
Link to this post: http://lists.isocpp.org/lib/2022/10/23961.php