35

我查看了Named Parameter IdiomBoost::Parameter library。每个人都比另一个人有什么优势?是否有充分的理由总是选择一个而不是另一个,或者在某些情况下它们中的每一个都比另一个更好(如果是,在什么情况下)?

4

6 回答 6

19

实现命名参数习语真的很简单,几乎和使用 Boost::Parameter 一样简单,所以它可以归结为一个要点。

- 你已经有提升依赖了吗?如果您不这样做,则 Boost::parameter 不够特别,不值得添加依赖项。

就我个人而言,我从未在生产代码中看到过 Boost::parameter,100% 的时间它都是命名参数的自定义实现,但这不一定是一件好事。

于 2008-10-15T04:14:09.390 回答
16

通常,我是 Boost 的忠实拥护者,但我不会使用 Boost.Parameter 库有几个原因:

  1. 如果您不知道发生了什么,则该调用看起来就像您在进行调用之前为调用函数范围内的变量分配了一个值。这可能非常令人困惑。
  2. 一开始就需要太多样板代码来设置它。
于 2008-10-15T12:21:56.347 回答
9

还有一点,虽然我从未使用过命名参数惯用语,但我使用 Boost Parameter 来定义多达 20 个可选参数。而且,我的编译时间很疯狂。过去需要几秒钟,现在需要 30 秒。如果您有一个使用您使用 boost 参数编写的小应用程序的东西库,那么这会增加。当然,我可能会错误地实现它,但我希望这会改变,因为除此之外,我真的很喜欢它。

于 2011-07-27T23:45:32.937 回答
2

命名参数习语要简单得多。我(现在)不明白为什么我们需要 Boost::Parameter 库的复杂性。(即使是假定的“特征”推导参数,似乎也是引入编码错误的一种方式;))

于 2008-10-15T07:53:37.387 回答
2

您可能不希望 Boost.Parameter 用于一般应用程序逻辑,而希望它用于您正在开发的库代码,它可以为库的客户端节省大量时间。

于 2008-10-21T22:45:23.417 回答
0

从来没有听说过,但是查看链接,命名参数更容易理解。我会在 boost 实施中迅速选择它。

于 2008-10-15T04:48:43.593 回答