避免使用 std::function 和成员函数分配内存

Question

此代码仅用于说明问题。

#include <functional>
struct MyCallBack {
    void Fire() {
    }
};

int main()
{
    MyCallBack cb;
    std::function<void(void)> func = std::bind(&MyCallBack::Fire, &cb);
}

valgrind 的实验表明，分配给func 的行在 linux 上使用 gcc 7.1.1 动态分配了大约 24 个字节。

在实际代码中，我有几个不同的结构，它们都有一个 void(void) 成员函数，存储在大约 1000 万个 std::function<void(void)> 中。

有什么办法可以避免在执行 std::function<void(void)> func = std::bind(&MyCallBack::Fire, &cb); 时动态分配内存？ （或者以其他方式将这些成员函数分配给std::function）

Answer 1

很遗憾，std::function 的分配器已在 C++17 中删除。

现在，避免在 std::function 中进行动态分配的公认解决方案是使用 lambdas 而不是 std::bind。这确实有效，至少在 GCC 中 - 它有足够的静态空间来存储您的情况下的 lambda，但没有足够的空间来存储活页夹对象。

std::function<void()> func = [&cb]{ cb.Fire(); };
    // sizeof lambda is sizeof(MyCallBack*), which is small enough

作为一般规则，对于大多数实现以及仅捕获单个指针（或引用）的 lambda，您将避免使用此技术在 std::function 内进行动态分配（与其他答案一样，它通常也是更好的方法建议）。

请记住，要使其工作，您需要保证此 lambda 将比 std::function 寿命更长。显然，这并不总是可能的，有时您必须通过（大）副本来捕获状态。如果发生这种情况，目前没有办法消除函数中的动态分配，除了自己修补 STL（显然，一般情况下不推荐，但在某些特定情况下可以这样做）。

Answer 2

作为已经存在的正确答案的附录，请考虑以下内容：

MyCallBack cb;
std::cerr << sizeof(std::bind(&MyCallBack::Fire, &cb)) << "\n";
auto a = [&] { cb.Fire(); };
std::cerr << sizeof(a);

这个程序用 gcc 和 clang 为我打印 24 和 8。我不完全知道 bind 在这里做什么（我的理解是它是一个极其复杂的野兽），但正如你所见，与 lambda 相比，它的效率几乎低得荒谬。

碰巧的是，std::function 保证不会分配，如果从函数指针构造，它也是一个字大小。因此，从这种 lambda 构造一个std::function，它只需要捕获一个指向对象的指针并且也应该是一个单词，实际上应该永远不会分配。

Answer 3

运行这个小技巧，它可能会打印出你可以在不分配内存的情况下捕获的字节数：

#include <iostream>
#include <functional>
#include <cstring>

void h(std::function<void(void*)>&& f, void* g)
{
  f(g);
}

template<size_t number_of_size_t>
void do_test()
{
  size_t a[number_of_size_t];
  std::memset(a, 0, sizeof(a));
  a[0] = sizeof(a);

  std::function<void(void*)> g = [a](void* ptr) {
    if (&a != ptr)
      std::cout << "malloc was called when capturing " << a[0] << " bytes." << std::endl;
    else
      std::cout << "No allocation took place when capturing " << a[0] << " bytes." << std::endl;
  };

  h(std::move(g), &g);
}

int main()
{
  do_test<1>();
  do_test<2>();
  do_test<3>();
  do_test<4>();
}

gcc version 8.3.0 打印出来

捕获 8 个字节时未进行分配。
捕获 16 个字节时未进行分配。
捕获 24 个字节时调用 malloc。
捕获 32 个字节时调用了 malloc。

Answer 4

许多 std::function 实现将避免分配并使用函数类本身内部的空间，而不是在它包装的回调“足够小”并且具有微不足道的复制时进行分配。但是，该标准并不要求这样做，只是建议这样做。

在 g++ 上，函数对象上的重要复制构造函数或超过 16 个字节的数据足以使其分配。但是如果您的函数对象没有数据并使用内置的复制构造函数，则 std::function 将不会分配。 另外，如果你使用函数指针或成员函数指针，它不会分配。

虽然不是您问题的直接部分，但它是您示例的一部分。 不要使用 std::bind。几乎在所有情况下，lambda 都更好：更小、更好的内联、可以避免分配、更好的错误消息、更快的编译，等等。如果要避免分配，还必须避免绑定。

Answer 5

我为您的特定用途提出了一个自定义类。

虽然您确实不应该尝试重新实现现有的库功能，因为这些库的功能会经过更多测试和优化，但它也适用于一般情况。如果您遇到示例中的特殊情况，并且标准实现不适合您的需求，您可以探索实现针对您的特定用例量身定制的版本，您可以根据需要对其进行衡量和调整。

所以我创建了一个类似于std::function<void (void)> 的类，它仅适用于方法并且所有存储都已到位（无动态分配）。

我亲切地称它为Trigger（灵感来自您的Fire 方法名称）。如果你愿意，请给它一个更合适的名字。

// helper alias for method
// can be used in user code
template <class T>
using Trigger_method = auto (T::*)() -> void;

namespace detail
{

// Polymorphic classes needed for type erasure
struct Trigger_base
{
    virtual ~Trigger_base() noexcept = default;
    virtual auto placement_clone(void* buffer) const noexcept -> Trigger_base* = 0;

    virtual auto call() -> void = 0;
};

template <class T>
struct Trigger_actual : Trigger_base
{
    T& obj;
    Trigger_method<T> method;

    Trigger_actual(T& obj, Trigger_method<T> method) noexcept : obj{obj}, method{method}
    {
    }

    auto placement_clone(void* buffer) const noexcept -> Trigger_base* override
    {
        return new (buffer) Trigger_actual{obj, method};
    }

    auto call() -> void override
    {
        return (obj.*method)();
    }
};

// in Trigger (bellow) we need to allocate enough storage
// for any Trigger_actual template instantiation
// since all templates basically contain 2 pointers
// we assume (and test it with static_asserts)
// that all will have the same size
// we will use Trigger_actual<Trigger_test_size>
// to determine the size of all Trigger_actual templates
struct Trigger_test_size {};

}

struct Trigger
{
    std::aligned_storage_t<sizeof(detail::Trigger_actual<detail::Trigger_test_size>)>
        trigger_actual_storage_;

    // vital. We cannot just cast `&trigger_actual_storage_` to `Trigger_base*`
    // because there is no guarantee by the standard that
    // the base pointer will point to the start of the derived object
    // so we need to store separately  the base pointer
    detail::Trigger_base* base_ptr = nullptr;

    template <class X>
    Trigger(X& x, Trigger_method<X> method) noexcept
    {
        static_assert(sizeof(trigger_actual_storage_) >= 
                         sizeof(detail::Trigger_actual<X>));
        static_assert(alignof(decltype(trigger_actual_storage_)) %
                         alignof(detail::Trigger_actual<X>) == 0);

        base_ptr = new (&trigger_actual_storage_) detail::Trigger_actual<X>{x, method};
    }

    Trigger(const Trigger& other) noexcept
    {
        if (other.base_ptr)
        {
            base_ptr = other.base_ptr->placement_clone(&trigger_actual_storage_);
        }
    }

    auto operator=(const Trigger& other) noexcept -> Trigger&
    {
        destroy_actual();

        if (other.base_ptr)
        {
            base_ptr = other.base_ptr->placement_clone(&trigger_actual_storage_);
        }

        return *this;
    }

    ~Trigger() noexcept
    {
        destroy_actual();
    }

    auto destroy_actual() noexcept -> void
    {
        if (base_ptr)
        {
            base_ptr->~Trigger_base();
            base_ptr = nullptr;
        }
    }

    auto operator()() const
    {
        if (!base_ptr)
        {
            // deal with this situation (error or just ignore and return)
        }

        base_ptr->call();
    }
};

用法：

struct X
{    
    auto foo() -> void;
};


auto test()
{
    X x;

    Trigger f{x, &X::foo};

    f();
}

警告：仅测试编译错误。

您需要彻底测试它的正确性。

您需要对其进行分析，看看它是否比其他解决方案具有更好的性能。这样做的好处是因为它是自家制作的，您可以对实现进行调整以提高特定场景的性能。