Den ons 21 sep. 2022 kl 03:07 skrev Patrice Roy via SG14 <
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]> a écrit :
>
>> On Tue, Sep 20, 2022 at 9:22 AM Bjarne Stroustrup via Lib <
>> 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://github.com/Quuxplusone/SG14/blob/ajo/include/sg14/inplace_function.h
>>
>> https://groups.google.com/a/isocpp.org/g/std-proposals/c/vven2Om7Ha8/m/C7qQ_XwVCwAJ
>>
>> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf
>>
>> 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.
>>
>> https://quuxplusone.github.io/blog/2019/03/27/design-space-for-std-function/
>> is related.
>>
>> HTH,
>> Arthur
>> _______________________________________________
>> Lib mailing list
>> Lib_at_[hidden]
>> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>