- 主题:C++新功能越多,程序员越省事,编译器越复杂
用 NATS 消息队列了。。
【 在 mango7788 的大作中提到: 】
: 那你们的rpc现在用的是啥?
--
FROM 218.76.62.*
我跟你有差不多的需求,拿boost就解决了
【 在 ylh0315 的大作中提到: 】
: 访问不了。
: 主要原理是把时间作为一个整数,以一个时刻为0点,1899.12.31:00:00:00.000000为0点,按照日,分,秒,微秒的粒度,表示为一个整数,就方便各种计算啦,需要的是,各种表示格式与整数的互相转换。
--
FROM 218.91.250.*
闰秒压根不想解决,我又不能预测未来,谁知道哪天地球公转又慢了,都用TAI算了
【 在 milksea 的大作中提到: 】
: 时区是一方面,闰秒之类也是大坑。不涉及日期就单纯多了。
--
FROM 218.91.250.*
我发现凡是用go做的基本系统模块都很垃圾
比如那个grpc
速度比ice 慢了不止一星半点
再就是这个NATS
只要数据量一大,就是内存狂涨
【 在 speedboy2998 的大作中提到: 】
: 用 NATS 消息队列了。。
:
--
FROM 172.58.30.*
赞!你和milksea是我时不时来看这版面的动力。
【 在 mvtec 的大作中提到: 】
: 我发现凡是用go做的基本系统模块都很垃圾
: 比如那个grpc
: 速度比ice 慢了不止一星半点
: ...................
--
FROM 61.185.187.*
这种带垃圾回收的都一个样
【 在 mvtec (mvtec) 的大作中提到: 】
: 我发现凡是用go做的基本系统模块都很垃圾
: 比如那个grpc
: 速度比ice 慢了不止一星半点
: 再就是这个NATS
--
FROM 114.254.1.*
对。那个整数是以格林威治时间为准。时区问题,是在格式转换时处理的。必须的。因为铁路列车时刻表要跨越时区的,比如中欧班列,北京莫斯科列车。
【 在 z16166 的大作中提到: 】
: 可能要根据时区考虑,比如夏令时
: 不考虑时区的,一般计算可能是有问题的。
: 比如我这里有人从网上搜的这个函数(搜常数11644473600能找到SO的原帖子)
: ...................
--
FROM 221.221.51.*
这种轮子恐怕没有十个也有八个
而且历法各种乱七八糟的细节不好玩
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 可以考虑发布到 github 上面去。不过先对比一下有没有已经做好的。这种基础功能,轮子还是特别多的。可以考虑找个做得好的,把自己的功能合并到那个项目里面去。
:
: 【 在 ylh0315 的大作中提到: 】
: : 我有一套简单通用的时间函数库,C的,想要不?
--
FROM 183.179.53.*
主要是C++代码的复杂度不太可控。
【 在 deusomax (deuso) 的大作中提到: 】
:
: 【 在 ABCDEFGHJKLM 的大作中提到: 】
: : linus 好像就是用C语言防止C++开发者混进linux内核
: :
--
FROM 183.179.53.*
【 在 fanci 的大作中提到: 】
: 主要是C++代码的复杂度不太可控。
代码的复杂度超过了内核的复杂度,有点喧宾夺主了。
--
FROM 117.133.20.*