是否有一种完全可移植的方式来检查clock_gettime（）或具有它的综合平台列表？

Question

我正在尝试编写一个小型C ++实用程序库，其中包括（实际上）几乎可以在任何平台上使用clock_gettime（）API。*基本上，我想检查clock_gettime（）是否存在，使用本机实现它是可用的，并且如果它不可用，则基于其他计时器API实现它。容易，对吗？我预计这将是非常微不足道的，所以很自然地，它几乎不可能按照我想要的方式去做。 ;）

这是我的问题：如果我希望用户能够透明地调用clock_gettime（）API，我需要我的头文件完全检测是否存在本机声明/定义：

• 乐观检测由于显而易见的原因不起作用：如果clock_gettime（）不存在但我的标头的预处理器宏认为它是，它将不会被定义，并且用户将收到编译器错误。
• 保守的检测更糟糕：如果clock_gettime存在且#included但我的标头没有检测到它，我自己的实现将与它发生冲突......我已经学会了编译器甚至不会抱怨的困难方式关于clock_gettime（）被重新定义。相反，如果你“覆盖”现有的clock_gettime（），你的函数将被调用，但是它将完全BIZARRE未定义的行为并崩溃或进入无限循环（即使你的回退实现没有任何循环）。

那么，有没有办法可靠地检测clock_gettime（）？我知道如果存在clock_gettime（），unistd.h应该定义_POSIX_TIMERS宏...但这是否保证每个实现？ （根据我的理解，它不是，但我可能是错的。）

• 如果是这样，我怎样才能可靠地检测unistd.h是否存在（它在Windows上不存在，至少在MSVC中存在，并且它出现在Linux / BSD上，但是有很多次要操作系统，等等。 ）？
• 如果没有，还有一个简单的头文件可以做些什么来可靠地检测它吗？

如果没有“自动”解决方案，是否有任何支持（或不支持）clock_gettime（）的所有平台的可靠，精确列表及其识别宏（对于那些不在http://sourceforge.net/p/predef/wiki/OperatingSystems/的人） ？这并不理想，因为随着新平台的出现，列表可能会失去同步，但它总比没有好。

我当然可以为我自己的小型库创建一个全新的计时器API。然后我可以保守地检测clock_gettime（）并在必要时回退到其他后端。这是一个很容易实现的明显解决方案，但是...谁想学习另一个愚蠢的计时器API？世界真的需要一个，只是为了解决没有内置机制的语言的愚蠢，以检测给定的函数是否已经存在？ ;）

*理由：为什么我不使用C ++ 11的std :: chrono？

1. C ++ 11 chrono接口不支持进程计时器，这对于某些类型的基准测试更为可取。这些计时器不会在每个平台上都可用，但我想尽最大努力使用它们，而clock_gettime（）是支持它们的最着名的现有接口。
2. 我希望这段代码能够在C ++ 03上运行，所以无论基础语言标准或操作系统如何，我都需要一致的用户界面...而且我无法重新实现整个C +没有它的平台上的+11 std :: chrono接口。那会很疯狂。