还有， 做成方法调用，自动完成会很方便， 用cast，都要自己手敲，花时间要多很多

【 在 z16166 的大作中提到: 】
: duration_cast是为了能在A、B之间按固定比例做任意转换，如果用A.milli_seconds()方法的办法，那需要加N种方法（如果以后扩展出天、年等单位，那还需要加方法），每种方法内部有N种模板匹配或者判断。还要考虑精度尽可能不损失。
: A（时、分、秒、毫秒、微秒、纳秒），6种
: B（时、分、秒、毫秒、微秒、纳秒），6种
: ...................
--
FROM 123.112.64.*

因为他们提供的count（）看不出什么单位，我还要经常查一下


【 在 z16166 的大作中提到: 】
: 所以你顶楼的代码为什么要调用duration_cast然后说这个封装脑子有问题呢？
: 为什么不自己除一下呢？
:
--
FROM 123.112.64.*

duration 提供了count（）和period，就可以满足对性能有极端要求的人，自己去算
再提供几个常用的函数，方便调用，这样是最理想的。

不提供这些函数，他们应该有考虑

1、调用者自己换算单位，可能数错0，编译器无法发现。
2、提供额外函数，增加了生成代码的体积，分离在不同模块，不用就不会包含在exe中。
3、这样的设计不“正交”，不符合c++和标准库的理念

这些考虑都有道理

但是不是多数普通程序员在意的。

标准库的开发者希望把所有东西都“类型化”，纳入编译器检查

但是这其实增加了开发者的学习成本和开发成本，不一定受程序员的欢迎。





【 在 z16166 的大作中提到: 】
: 这又是对硬件（时钟）的抽象了，要适配各种精度的时钟
: 但是在调用者不需要的情况下，不要进行数值转换，保持原样，因为调用者不需要的操作，那就是额外的开销。
: 这些是我临时想出来解释的，不一定对，看看就行，哈哈
: ...................
--
FROM 123.112.64.*

但是写零不容易搞混啊，数字可以加分隔符， 1'000'000
多清楚

用milli这些，还要加个头文件， 我还得知道milli到底是个啥


【 在 z16166 的大作中提到: 】
: 自己做除法，是error-prone的，人对数字把控的可靠度，远低于对符号的把控。
: 那个固定比例数值不需要调用者每次都手写。
: 我有时还会把milli second和micro second搞混，因为不是英语母语的人
: ...................
--
FROM 123.112.64.*

这样极端化，就是抬杠了

【 在 z16166 的大作中提到: 】
: 你想想码农为啥不用机器码写代码，而是要用汇编语言作为助记符
:
--
FROM 123.112.64.*