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