Question

我在我的库的开发中非常无聊，我想基于Windows消息标识符和WPARAM和LPARAM参数构建一个类。这些功能的原型很简单：

boost::shared_ptr<EventArgs>(const UINT& _id, const WPARAM& _w, const LPARAM& _l);

对于每个Windows消息，我将具有这种性质的功能。

现在，我目前正在使用FastDelegate库来代理我的代表。这些存储在地图中：

typedef fastdelegate::FastDelegate3<const UINT&, const WPARAM&, const LPARAM&, boost::shared_ptr<EventArgs> > delegate_type;
typedef std::map<int, delegate_type> CreatorMap;

当一个Windows消息需要创建一个EventArg派生类时，这是一个查找相应委托，调用它并返回一个很好地包含在{{1}中的新创建的实例的简单情况。 }。

shared_ptr

一切正常。但后来我想，为什么不利用C ++ 0x中的lambdas，而不是让所有这些代表都参与其中？所以，我快速制作了以下原型：

boost::shared_ptr<EventArgs> make(const UINT& _id, const WPARAM& _w, const LPARAM& _l) const
 {
  MsgMap::const_iterator cit(m_Map.find(_id));
  assert(cit != m_Map.end());
  boost::shared_ptr<EventArgs> ret(cit->second(_w, _l));
  return ret;
 }; // eo make

再一次，查找和调用很简单：

typedef std::map<int, std::function<boost::shared_ptr<EventArgs>(const WPARAM&, const LPARAM&)> > MapType;
typedef MapType::iterator mit;

MapType map;
map[WM_WHATEVER] = [](const WPARAM& _w, const LPARAM& _l) { /* create appropriate eventargs class given parameters */ };
map[WM_ANOTHER] = ....;
// and so on

以这种方式使用lambdas是否有优势？我知道查找正确的委托/ lambda的开销是相同的（因为两种类型的地图都用mit m = map.find(WM_PAINT); boost::shared_ptr<EventArgs> e(m->second(_wParam, _lParam)); // dispatch e键入），但我的目标是在我友好的C ++友好中从wndProc发送我的消息 - 方式尽可能高效。我的直觉是lambdas会更快，但遗憾的是我缺乏理解编译器优化的经验来对此做出判断，因此我的问题在这里:)哦，并且与问题的主题保持一致，是否存在任何陷阱/我没想过的东西？

Answer 1

我在这里看到两个真正的区别：

第一个是如何存储回调：fast-delegate或std :: function。后者基于boost :: function，快速代理专门设计为优于那些。但是，std :: function符合标准，而快速代理则不符合。

另一个不同之处在于您设置代码的方式，我在这里看到了lambdas的明显优势。您可以将实际代码准确地写在重要的位置，您不需要定义仅用于特定目的的单独函数。

如果你想要原始速度 - 快速代表可能会获胜（但你应该进行基准测试，如果这是一个参数），但是如果你想要可读性和标准符合性，那么请使用std :: function和lambdas。

在集合中使用函数委托而不是lambdas是否有任何优点/缺点？

1 个答案: