Question

我正在设计一个RGBA类，其中需要将四个参数传递给类的构造函数，以实例化该类。构造函数如下所示：

RGBA(int red = 0, int green = 0, int blue = 0, int alpha = 255)
{
    auto valid_color = [](int param) {return (param >= 0 && param <= 255) ? param : 0; };
    m_red = valid_color(red);
    m_green = valid_color(green);
    m_blue = valid_color(blue);
    m_alpha = valid_color(alpha);
}

正如您在上面所看到的，我已经为每个参数使用了lambda来验证传递的参数。这让我想知道，这样一个lambda对函数有什么优势，比如这个（在接口中声明为private）：

int valid_color(int param)
{
    return (param >= 0 && param <= 255) ? param : 0;
}

所以我的选择是：

继续使用lambda，让代码为。
而不是lambda，声明一个实际的函数，就像上面那个，并使用它。
完全把它写出来。（稍微单调乏味且容易出错）。

哪个选项似乎最好，为什么？

Answer 1

好吧，如果你使用lambda，你就不能这样做：

RGBA(int red = 0, int green = 0, int blue = 0, int alpha = 255)
    : m_red{valid_color(red)}
    , m_green{valid_color(green)}
    , m_blue{valid_color(blue)}
    , m_alpha{valid_color(alpha)}
{}

这使用构造函数初始化列表来初始化成员，而不是在构造函数体内执行它。

此外，您的成员函数应该是静态成员函数。或者是内部全局/命名空间范围的函数。它没有使用this。

Answer 2

如果有可能需要调用validate_color的其他函数，则将其设为函数。否则，它并不重要。

Answer 3

您的示例很简单，两种解决方案都具有相同的可读性和清晰度，并且没有特定的优势。

然而，如果你必须验证除了那个构造函数之外的其他上下文中的参数，并且你开始在任何地方复制lambda函数，那么你就会开始不必要地弄乱（例如，你运行如果你必须改变你的验证规则就麻烦了）。如果这是一种可能性或者开始发生的话，那就是使它成为一个成员函数的好例子，即使是一个static（因为它实际上不需要this来完成它的工作）。 / p>

顺便说一下：

完全把它写出来。（稍微单调乏味且容易出错）。

是的，不要那样做。正如您已经确定的那样，它有点单调乏味且容易出错，并且容易出错，＆lt;在这里插入deity＆gt;知道软件开发已经有了足够的乏味，不要惩罚自己。

在类构造函数中调用名为lambda的优点与调用实际的私有函数相比

3 个答案: