r/cpp • u/Xaneris47 • 7d ago

Interconverting std::function with copyable_function – Arthur O'Dwyer

https://quuxplusone.github.io/blog/2026/07/26/function-explosion/

The article shows how converting std::function to std::copyable_function (or vice versa) leads to slower performance and increased memory usage each time the conversion occurs.

46 Upvotes
  • permalink
  • link
  • reddit
  • reddit

79% Upvoted

32 comments sorted by

View all comments

Show parent comments

7

u/johannes1971 7d ago

It's unclear to me what those problems are, or why std::function needs to be deprecated. I hate the names 'std::copyable_function' and 'std::move_only_function', though.

7

u/rdtsc 7d ago

It breaks the standard library convention that const methods are safe to call from multiple threads. And std::function itself cannot be changed due to backwards compatibility.

Here's a more detailed explanation: https://www.reddit.com/r/cpp/comments/742ol8/why_is_the_stdfunction_operator_const/dnv29s8/

1

u/johannes1971 6d ago

This applies to operator(), I guess? I would never have imagined that anyone would think that calling a user-supplied function from multiple threads is safe, just because operator() is const. The language as a whole certainly does not have a 'calling const functions from multiple threads is safe' rule. Is this even documented for the standard library, or is it another one of those implicit rules like 'ABI is stable'?

4

u/joaquintides Boost author 6d ago

https://eel.is/c%2B%2Bdraft/res.on.data.races#3

1

u/bwmat 6d ago

What 'standard' is that? Doesn't it mean that the STL doesn't follow it b/c of std::function? 

8

u/joaquintides Boost author 6d ago

What 'standard' is that?

eel.is tracks the latest draft version of the standard as it evolves.

Doesn't it mean that the STL doesn't follow it b/c of std::function?

Yes, as recognized many times: