为什么 Boost 在 "Program Options" 中使用全局函数覆盖来实现自定义验证器

Why Does Boost Use a Global Function Override to Implement Custom Validators in "Program Options"

This example 显示在全局范围内定义的名为 validate 的函数重载 boost::program_options 命名空间中的函数。

使用全局函数重载这种设计的理由是什么?为什么 boost::program_options 没有实现更严格范围的设计(例如覆盖 class 方法或其他一些方案)?

如以下评论所述,我主要担心的是用户 可能 惊讶地发现库正在调用他们的全局函数之一。

需要强调的是 namespaced 自由函数非常重要(相对于全局范围的自由函数,参见 Chris Drew 提供的 this link)。实际上,命名空间、非 class(免费)函数是 IMO C++ 的主要优势。

我的公司正在考虑主要采用 Boost,它似乎受到高度重视。但是,这个特殊的设计决定让我担心。

一般来说,不同的boost库有不同的质量水平。

更具体地说,这涵盖了相对罕见的用户案例。我想可能会以不同的方式实现它,但作者选择了一条快速而简单的路线。虽然我同意全局函数并不完美,但它肯定没有全局变量那么糟糕。这些 validate 功能将自然限制为 main.cpp 或类似功能。

当然欢迎您对库提出改进建议或使用替代实现。我可以向你保证,在 boost 中有很多非常有用且设计良好的库,所以这个例子不会让你气馁。

I think my main surprise is that a function defined in a namespace can be overloaded (hidden) by a function defined at global scope. I'm going to ask why c++ allows that and whether anyone considers that a flaw unless you have a brief explanation handy.

不,这不能被视为缺陷。

该函数不会被在全局范围内定义的函数隐藏。

这就是参数相关查找 (ADL) 的用途,您一直在使用它!你在这里使用它:

std::cout << "Hello world!";

ADL 非常微妙而且非常普遍。许多人在问自己与您刚才问的相同类型的问题之前并没有意识到这一点。免费功能非常适合扩展点。

更多:What is "Argument-Dependent Lookup" (aka ADL, or "Koenig Lookup")?