问题描述
在C ++ 11中，您仍然必须使用 std :: localtime 和 std :: gmtime 作为间接打印 std :: chrono :: time_point 。这些函数在C ++ 11引入的多线程环境中不能安全使用，因为它们会返回指向内部静态结构的指针。由于C ++ 11引入了方便的功能 std :: put_time ，由于相同的原因，该功能几乎无法使用，这特别令人讨厌。
In C++11 you still have to use std::localtime and std::gmtime as indirection to print a std::chrono::time_point. These functions are not safe to use in a multithreaded environment as introduced with C++11 because they return a pointer to an internal static struct. This is especially annoying since C++11 introduced the convenient function std::put_time which is nearly unusable for the same reason.
为什么这么根本性的破坏或我忽略了什么？
Why is this so fundamental broken or do I overlook something?
推荐答案
根据，该文件添加了< chrono> ：
本文没有提出通用的物理量
库。
This paper does not propose a general purpose physical quantities library.
该提案的主要目标是以一种易于使用，安全使用
，高效且灵活到不被淘汰10甚至什至是的方式满足
标准库线程API的需求。
从现在开始100年了。出于特定原因，此处以实际用例为动机，为此提案中包含的每个功能都是
。属于
的事物属于酷类别，或者听起来像
有用，或者非常有用，但此接口不需要，因此未包含
。此类项目可能会出现在其他提案中，并且
可能定位到TR。
The major goal of this proposal is to satisfy the needs of the standard library threading API in a manner which is easy to use, safe to use, efficient, and flexible enough to not be obsolete 10 or even 100 years from now. Every feature contained in this proposal is here for a specific reason with practical use cases as motivation. Things that fell into the category of "cool", or "that sounds like it might be useful", or "very useful but not needed by this interface" have not been included. Such items might appear in other proposals, and possibly target a TR.
请注意，<$ c的主要目标$ c>< chrono> 是满足标准库线程API的需求，不需要日历服务。
Note that the major goal of <chrono> is "to satisfy the needs of the standard library threading API", which does not require calendar services.
这篇关于为什么没有C ++ 11线程安全替代std :: localtime和std :: gmtime？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！