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_at_[hidden]> On Behalf Of Björn Andersson via Lib
Sent: Monday, October 3, 2022 11:58 AM
To: sg14_at_[hidden]
Cc: Björn Andersson <bjorn.andersson_at_[hidden]>; lib_at_[hidden]; Patrice Roy <patricer_at_[hidden]>
Subject: [EXTERNAL] Re: [isocpp-lib] [SG14] std::function

Den ons 21 sep. 2022 kl 03:07 skrev Patrice Roy via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>>:
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_at_[hidden]<mailto:lib_at_[hidden]>> a écrit :
On Tue, Sep 20, 2022 at 9:22 AM Bjarne Stroustrup via Lib <lib_at_[hidden]<mailto:lib_at_[hidden]>> 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:
https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h<https://urldefense.com/v3/__https:/github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDabzpusS$>
https://github.com/Quuxplusone/SG14/blob/ajo/include/sg14/inplace_function.h<https://urldefense.com/v3/__https:/github.com/Quuxplusone/SG14/blob/ajo/include/sg14/inplace_function.h__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDVgSckTs$>
https://groups.google.com/a/isocpp.org/g/std-proposals/c/vven2Om7Ha8/m/C7qQ_XwVCwAJ<https://urldefense.com/v3/__https:/groups.google.com/a/isocpp.org/g/std-proposals/c/vven2Om7Ha8/m/C7qQ_XwVCwAJ__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDQVrHXUy$>
https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf<https://urldefense.com/v3/__https:/github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDZ7r8JVu$>

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<https://urldefense.com/v3/__https:/github.com/WG21-SG14/SG14/issues/125__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDXFqTwly$> inspired the implicit-move changes in C++20 (P1155 More Implicit Move).
https://github.com/WG21-SG14/SG14/issues/150<https://urldefense.com/v3/__https:/github.com/WG21-SG14/SG14/issues/150__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDUy1jqED$> 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.
https://quuxplusone.github.io/blog/2019/03/27/design-space-for-std-function/<https://urldefense.com/v3/__https:/quuxplusone.github.io/blog/2019/03/27/design-space-for-std-function/__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDVs2z3X3$> is related.

HTH,
Arthur
_______________________________________________
Lib mailing list
Lib_at_lists.isocpp.org<mailto:Lib_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/lib__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDWOp6UJJ$>
Link to this post: http://lists.isocpp.org/lib/2022/09/23737.php<https://urldefense.com/v3/__http:/lists.isocpp.org/lib/2022/09/23737.php__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDa3aziyr$>
_______________________________________________
SG14 mailing list
SG14_at_[hidden]<mailto:SG14_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg14__;!!FbZ0ZwI3Qg!sCasIrYyAVDki7IUP5cdc4SyHRAN353p0v57WEjq1yngDBDosdG3aIVmMqax8UEo369IDcXjZ4Fg$>


INTERNAL - NI CONFIDENTIAL