================ @@ -0,0 +1,93 @@ +//===----------------------------------------------------------------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#ifndef _LIBCPP___FUNCTIONAL_MOVE_ONLY_FUNCTION_H +#define _LIBCPP___FUNCTIONAL_MOVE_ONLY_FUNCTION_H + +#include <__config> + +#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER) +# pragma GCC system_header +#endif + +#if _LIBCPP_STD_VER >= 23 + +// move_only_function design: +// +// move_only_function has a small buffer with a size of `3 * sizeof(void*)` bytes. This buffer can only be used when the +// object that should be stored is trivially relocatable (currently only when it is trivially move constructible and +// trivially destructible). There is also a bool in the lower bits of the vptr stored which is set when the contained +// object is not trivially destructible. +// +// trivially relocatable: It would also be possible to store nothrow_move_constructible types, but that would mean +// that move_only_function itself would not be trivially relocatable anymore. The decision to keep move_only_function +// trivially relocatable was made because we expect move_only_function to be mostly used to store a functor. To only +// forward functors there is std::function_ref (not voted in yet, expected in C++26). +// +// buffer size: We did a survey of six implementations from various vendors. Three of them had a buffer size of 24 bytes +// on 64 bit systems. This also allows storing a std::string or std::vector inside the small buffer (once the compiler +// has full support of trivially_relocatable annotations). +// +// trivially-destructible bit: This allows us to keep the overall binary size smaller because we don't have to store +// a pointer to a noop function inside the vtable. It also avoids loading the vtable during destruction, potentially +// resulting in fewer cache misses. The downside is that calling the function now also requires setting the lower bits +// of the pointer to zero, but this is a very fast operation on modern CPUs. ---------------- philnik777 wrote:
I'd think so, yes. Fortunately it seems a lot easier in that case, since `function_ref` will probably only store a pointer to the object and a pointer to the function. https://github.com/llvm/llvm-project/pull/94670 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits