基于特征的自定义点和{fmt}中的ODR违反关注点
提问于 2018-10-29 14:40:19
首先，我目前正在为我的论文学习C++，因此我对这门语言缺乏经验。任何帮助都是非常感谢的。
我在代码中使用fmt库，用户提供的格式化类型的规范方式是专门化类模板类型fmt::formatter。
示例
编译器资源管理器中的代码：wa
给定两个库( A和B )，这两个库在实现过程中碰巧都大量使用fmt，并且在某种程度上都需要打印/记录当前时间。两者都可能合理地使用std::chrono::system_clock，并希望在几个点对其进行格式化，每一个都定义自己的fmt::formatter<std::chrono::system_clock::time_point>版本，以便使这段简单的代码成为可能：
auto msg = fmt::format("It is now {}", std::chrono::system_clock::now());库A使用与B不同的实现，因为它考虑了本地时区，而不是在UTC中打印。
现在这个例子非常具体，但是由于类模板fmt::formatter是格式化用户提供的类型的方法，这种场景可能以一种或另一种形式出现。
问题
当我开发我的应用程序C并同时使用(不相关的)库A和B时，我相信会有两个相同类型的不同实现(即fmt::formatter<std::chrono::system_clock::time_point>)，从而违反了ODR的未定义行为。
问题
假设我对情况的理解是正确的，我的两个问题是：
- 有没有一种方法可以避免应用程序
C中的冲突而不改变上游的A和B？ - 如果可以修改
A或B(或两者都可以)，冲突可以以什么方式解决或完全防止。
回答 1
Stack Overflow用户
回答已采纳
发布于 2018-10-29 14:50:13
- 是否有办法避免应用程序C中的冲突而不改变A和B上游？
你确实违反了ODR，我认为你不能避免冲突而不改变A和/或B。
- 如果A或B(或两者都可以修改)，冲突可以以什么方式得到解决或完全防止。
只专门化您自己库的类型:所以在库A中，在std::chrono::system_clock::time_point周围创建包装器
namespace A {
struct TimePoint {
std::chrono::system_clock::time_point timePoint;
};
}
namespace fmt {
// Specialization of formatter<TimePoint>
}然后
auto msg = fmt::format("It is now {}", A::TimePoint{std::chrono::system_clock::now()});图书馆B也是如此。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/53054931
复制
腾讯云开发者
