麻烦是ctime，time.h，sys / time.h

Question

我希望一些Linux顽固的人可以回答我在处理时间函数时应该如何编写可移植（POSIX）代码。

• 包括ctime在内的Some SO threads suggest在编写C ++代码时是正确的做法，而你仍然会为C代码包含time.h。但是，它们都定义了相同的功能，尽管在不同的命名空间中。从技术上讲，你应该能够指定两者。
• 一篇SO帖子建议一个人应该避免使用基于sys / *的包括all ..
• ..虽然这个thread暗示在包含sys / resources.h之前必须包含sys / time.h，特别是对于基于BSD的平台。
• This post说包括sys / time.h提高了可移植性。我想海报认为它允许你链接更多使用gettimeofday等特定功能的第三方图书馆..但是..
• gettimeofday（）一直是discouraged，现在正在享受deprecated状态，所以我应该使用clock_gettime（）代替。这个clock_gettime（）在time.h中定义，参见https://linux.die.net/man/3/clock_gettime ..
• ..如果安装并链接libavutil（例如作为ffmpeg-dev的一部分），很明显time.h was created to drive people nuts。 Ffmpeg（以及其他一些libs）拥有自己的time.h，甚至还有timeb.h。事实证明，如果构建堆栈中任何地方的任何.c或.cpp都包含time.h，并且include路径包含多个有效条目（including the one for ffmpeg），则可能引用错误的条目，并且只是替换声明。 @ FFmpeg，推理似乎是ugly hack足以解决问题。我还没那么幸运。此外，Php-izing所有来源根本不是一个解决方案。
• 另一个time.h存在于我的系统上的usr / include / i386-linux-gnu / bits中，所以这也不是一个只有ffmpeg的现象。简单地将usr / include / i386-linux-gnu称为包含路径因此变得致命，这在引用系统包含时是奇怪的。
• 我重写了我的CMake脚本，注意使用dedicated include folder specs来实现大多数目标。我已经尝试将time.h / ctime和sys / time.h中的各种排列包含在整个代码库中引用的预编译头中。我仍然得到如下错误：

错误：字段'st_atim'具有不完整类型'timespec'，struct timespec st_atim;

错误：':: time'尚未声明

等等..

因此，对于与许多第三方依赖关系链接的C ++设置，确保所有内容一直在编译w.r.t的正确方法是什么。包括time.h？我应该将time.h包含在我正在编译的特定平台上吗？我应该查看可能需要time.h的所有目标吗？跳舞大象和五彩纸屑躺在前面。

---

更新：该问题似乎与C ++版本有关，如下面的评论中所暗示的那样。我已经将gcc更新到8.3.0（从5.4），并且我已经放弃了在linux下支持c ++ 11以下的旧c ++兼容性。在更新并重建所有第三方软件包（包括ffmpeg）之后，我现在不再遇到我所描述的问题，但这并不意味着它已被修复，因为它不能再为其他人发生。事实上，我认为问题主要在于ffmpeg如何编译旧编译器并且没有明确请求c ++ 11，所以我将其保持开放状态。

Answer 1

我建议你考虑一下Howard Hinnant的date库已被接受进入下一版C++标准库（C++20）：

https://github.com/HowardHinnant/date

它应该适用于任何支持C++11的平台。

标准版本记录在这里：https://en.cppreference.com/w/cpp/chrono