函子与模板参数

发布于 2024-10-06 17:31:49 字数 763 浏览 7 评论 0原文

将模板参数与静态成员函数一起使用而不是函子样式谓词时，是否有任何性能优势？

例如，函子样式的排序接口通常是这样的：

template <typename _Type, typename _Pred>
void sort (
    RandomAccessIterator first,
    RandomAccessIterator last ,
    _Pred less_than
    )
{
// actual sorting code here, calling less_than()...
}

您可以做类似这样的事情，并要求 _Pred 包含静态成员函数 _Pred::less_than ：

template <typename _Type, typename _Pred>
void sort (
    RandomAccessIterator first,
    RandomAccessIterator last
    )
{
// actual sorting code here, calling _Pred::less_than()...
}

理论上，第一种情况可能会在堆上动态创建一个临时函子对象，而我相信第二种情况在编译时已完全评估。我知道（比如说）gcc 和/或 msvc 擅长优化，但是在第一种情况下可以达到相同的程度吗？

另外，我并不是想重写 STL 排序例程或类似的东西，只是一个更一般的函子问题的例子......

原文

Is there any performance advantage to be had when using template parameters with static member functions instead of functor-style predicates??

For instance, a functor-style sort interface is typically something like this:

template <typename _Type, typename _Pred>
void sort (
    RandomAccessIterator first,
    RandomAccessIterator last ,
    _Pred less_than
    )
{
// actual sorting code here, calling less_than()...
}

You could do something more like this, and require that _Pred contained a static member function _Pred::less_than:

template <typename _Type, typename _Pred>
void sort (
    RandomAccessIterator first,
    RandomAccessIterator last
    )
{
// actual sorting code here, calling _Pred::less_than()...
}

In theory, the first case might dynamically create a temporary functor object on the heap, whereas I believe that the second case is fully evaluated at compile time. I understand that (say) gcc and/or msvc are good at optimising, but can this be done to the same degree in the first case??

Also, I'm not trying to rewrite the STL sort routines or anything like that, just an example for a more general functor question...

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

妞丶爷亲个 2024-10-13 17:31:49

正常使用 sort 不会在堆上放置任何内容，原因很简单，没有人调用 malloc 或 new。如果您的谓词导致在其构造函数或比较中调用 malloc 或 new，那么您只能责怪自己......

某些堆栈可能会用于 _Pred 类型的参数（您不能在代码中调用模板参数 _Pred，因为 _Pred 是保留符号。它可以在 std::sort 的实现中调用它）。但是，除了谓词对象可能具有的任何数据成员所必需的之外，不会有任何关联的工作要做。如果谓词没有数据成员，那么优化器将有一个字段日，如果它确实有数据成员，那么静态成员函数将不支持用户想要执行的操作。

只要谓词中的 operator() 是非虚拟的，编译器就可以将其内联到 sort 的实例化中（如果它可以看到定义并且认为这是最好的）。当然，不能保证哪个更快，但是没有理由假设对静态成员函数的调用比对非虚拟非静态成员函数的调用更快或更慢，也没有理由认为调用静态成员函数更容易或更难排队。

回复收藏 0 原文

打小就很酷 2024-10-13 17:31:49

理论上，第一种情况可能
动态创建临时函子
堆上的对象，而我相信
第二种情况完全
在编译时评估。

第一种情况将在堆栈上创建一个临时函子对象。您是否担心 Pred::Pred() 是否会分配存储？如果是这样，您可能还担心静态函数是否会出于某种原因在堆上分配存储空间。

无论如何，大多数使用这种习惯用法的谓词函子对象都具有非常简单的构造函数，因为它们的唯一目的是调用重载的运算符 ()，因此编译器可能会优化对象构造并生成一个简单的函数调用。

回复收藏 0 原文

本王不退位尔等都是臣 2024-10-13 17:31:49

在第一种情况下，您可以创建一个

template<class T>
struct CompareByIntProperties {
    CompareByIntProperties(vector<T::*int> props) : props_(props) {}
    bool less_than(const T& a, const T& b) const {
        for (vector<T::*int>::const_iterator it = props_.begin();
             it != props_.end(); ++it) {
            if (a.(**it) < b.(**it)) return true;
            if (a.(**it) > b.(**it)) return false;
        }
        return false;
    }
    vector<T::*int> props_;
};

允许您

vector<Foo::*int> properties;
if (compare_foo) properties.push_back(&Foo::foo);
if (compare_bar) properties.push_back(&Foo::bar);
if (compare_qux) properties.push_back(&Foo::qux);
sort(container.begin(), container.end(), CompareByIntProperties<Foo>(properties));

“请原谅任何语法错误”的文件，这些错误都没有经过编译检查。但你明白了。

在第二种情况下，因为您正在调用静态方法，所以您没有自由支配像这样自定义比较器。

我不会担心效率。如果您不访问任何非静态的内容，一个好的 C++ 编译器将消除额外的对象创建/销毁，甚至可能内联比较器。

In the first case, you could create a

template<class T>
struct CompareByIntProperties {
    CompareByIntProperties(vector<T::*int> props) : props_(props) {}
    bool less_than(const T& a, const T& b) const {
        for (vector<T::*int>::const_iterator it = props_.begin();
             it != props_.end(); ++it) {
            if (a.(**it) < b.(**it)) return true;
            if (a.(**it) > b.(**it)) return false;
        }
        return false;
    }
    vector<T::*int> props_;
};

which would allow you to

vector<Foo::*int> properties;
if (compare_foo) properties.push_back(&Foo::foo);
if (compare_bar) properties.push_back(&Foo::bar);
if (compare_qux) properties.push_back(&Foo::qux);
sort(container.begin(), container.end(), CompareByIntProperties<Foo>(properties));

Please forgive any syntax errors, none of this has been compile-checked. But you get the idea.

In the second case, because you're calling a static method, you do not have free reign to customize the comparator like this.

I wouldn't worry about efficiency. If you're not accessing anything non-static, a good C++ compiler will elide the extra object creation/destruction and possibly even inline the comparator.

回复收藏 0 原文