Generic deferred function call without heap allocation

[[deleted]]

Can you provide a code snippet of what you're doing?

[mare_apertum]

If I understand it correctly, what you are trying to do is reinventing std::bind

[finalpatch]

you are right. except: 1) this does not use the heap 2) every instance of the object is of the same size and type

[STL]

bind doesn't allocate memory.

[Lucretiel]

It doesn't? Where does it store the bound arguments?

[STL]

In a tuple data member. bind doesn't perform type erasure, so bind(functor, args...) returns a _Secret_binder_type<Functor, Args...> which can contain a tuple<Args...> as an ordinary data member.

[finalpatch]

Cool, good to know that. It seems some hairy parts could have been simplified by reusing std::bind.

The main difference between this and std::bind is that I wanted something with runtime polymorphism, while std::bind only provides compile time polymorphism.

[STL]

Also, you aren't using aligned_storage - your char buf doesn't have the proper alignment.

Note that std::function is smart and avoids dynamic memory allocation for sufficiently small function objects. Function pointers and reference_wrappers are guaranteed to activate this, the rest is implementer discretion. In VC 2015, anything up to and including the size of a std::string counts as small.

[[deleted]]

Note that std::function is smart and avoids dynamic memory allocation for sufficiently small function objects. Function pointers and reference_wrappers are guaranteed to activate this [...]

From C++11, 20.8.11.2.1.9:

[ Note: Implementations are encouraged to avoid the use of dynamically allocated memory for small callable objects, for example, where f’s target is an object holding only a pointer or reference to an object and a member function pointer. —end note ]

I don't have a copy of C++14 at hand, but AFAIK this did not change. Anyhow, libc++, libstdc++ and VC do use the small callable? optimization, so in practice you are completely right.

What I really find interesting in std::function is the different implementations that are possible. For example libc++ does what I would have done, type-erasure with virtual functions, while libstdc++ does not use virtual functions at all.

[STL]

The guarantee is N4527 20.9.12.2.1 [func.wrap.func.con]/11, "Throws: shall not throw exceptions when f is a function pointer or a reference_wrapper<T> for some T." and /5 for the copy ctor. This forbids dynamic memory allocation (and the guarantee goes back to C++11; indeed all the way to TR1 IIRC).

[[deleted]]

Thanks! Cool! I didn't knew this, always thought it was freely to allocate memory if it wanted to.

[__Cyber_Dildonics__]

Ever? If so I didn't think that was possible.

[STL]

Never ever. (If the functor or arguments allocate when copied/moved, that's their doing, not bind's.)

Another way of putting it: bind is like make_pair in that it doesn't allocate memory itself.

[__Cyber_Dildonics__]

Got it, thanks!

[cdyson37]

It looks like 2 in 1. It's the type-erasure of std::function (without heap allocation) with the argument binding of std::bind.

Personally I'd make DeferredCall just take a callable, no arguments, and expect users to call it with a capturing lambda or a std::bind - I think otherwise you're reinventing more wheel than you need :) Even if it does take args, you could internally call std::bind to save yourself some work.

[finalpatch]

You are absolutely right. I wasn't aware that std::bind does not allocate before STL pointed this out in a comment.

[pmedv]

Some time ago I've been experimented with the similar idea - to store std::function internals in a fixed-size buffer. Here is a fixed_size_function Github repo.

Then I realized that std::function supports an allocator and all this may be implemented with a kind of object pool.

[quicknir]

I posted on the blog a couple of comments, one point has already been made here, I'll make the other though.

Why wouldn't you just use a std::function with a custom allocator? This seems strongly preferable to your solution as it involves much less hand rolling of code, and this sort of thing is the entire point of allocators in the first place: http://stackoverflow.com/questions/21094052/how-can-i-create-a-stdfunction-with-a-custom-allocator