[PATCH] D55045: Add a version of std::function that includes a few optimizations.

Louis Dionne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 3 13:08:06 PST 2018


ldionne added a comment.

Eric and I just spoke. My point of view:

We should investigate factoring out the functions that differ in implementation into separate classes with a common API. This way, we could have something like this:

  template<class _Rp, class ..._ArgTypes>
  class function<_Rp(_ArgTypes...)> {
  #ifndef _LIBCPP_ABI_OPTIMIZED_FUNCTION
      typedef __function::__abi_v1_impl<_Rp(_ArgTypes...)> __implementation;
  #else
      typedef __function::__abi_optimized_impl<_Rp(_ArgTypes...)> __implementation;
  #endif
  
      __implementation __impl_;
  
      ...
  };

Then, in the copy constructor, something like:

  template<class _Rp, class ..._ArgTypes>
  function<_Rp(_ArgTypes...)>::function(const function& __f) {
      __impl_.copy_construct(__f.__impl_);
  }

And something analogous for other operations. This way, the implementation of each storage/dispatching mechanism would be collocated with itself and we could conceivably add new ones or introduce a new one in a future ABI version. There's also a possibility that we could reuse some of this logic (the SBO logic) in other components like `std::any`. We could also test those two implementations individually in some libc++-specific tests instead of leaving the new implementation go largely untested. I also think it would make the code cleaner than using `#ifdef`s all over the place, but that's subjective.

I'd like this avenue to be explored -- if it turns out not to be a fruitful approach, then I can live with the current approach.


Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55045/new/

https://reviews.llvm.org/D55045





More information about the llvm-commits mailing list