背景 早先社区报过 opentelemetry-cpp 在GCC 14中编译不通过的问题。最近我也是先升级我们项目组的工具链,主要也是把GCC升级到GCC 14,这时候发现有些第三方

之前搞 opentelemetry-cpp 的时候接触了下 bazel 构建系统。这玩意儿用起来有一点坑,特别是使用自定义编译环境的时候。 在使用我自己编译的很新版本的 GCC 和 clang+libc++ 的时候,涉及对l

可能是疫情的原因,GCC好久没发布啦。最近总于又Release了,还是大版本。并且三大编译器对C++20的支持也都七七八八了。所以特意立贴庆

开始之前 很多语言的log模块都有一个功能,就是在打log的时候能够追溯调用栈,有的时候对查bug能有点帮助。之前我也想过给我们的log模块加

之前测出来libcopp还有一些列优化点,但是要破坏之前的API,所以整理了一下优化的想法和方案。 预留空间和合并分配 之前有太多的堆内存分配了

在写这篇文章前,我突然想到以前流行了一段时间的服务器面试题:当一个BUG只有几百万分之一的概率会出现,怎么办?这个问题在这个BUG里只是毛毛

近期仍然在搭建完整的游戏服务器架构。基于atsf4g(asynchronously-tree server framework fo game)的完整解决方案终于接近完成。基本

好久没写blog了。最近空闲时间都在加紧完成atframework框架。总算是搞完了,并且搭建了一个静态介绍页。以后有空慢慢加文档进去。 主页

我们目前的游戏第一次测试的时候笔记送匆忙,导致上线之后频繁更新。 比如BOSS战由于大区的人数和预期不一样导致的难度调整,或者是任务链或者数值

这个问题起源于以前给客户端写的一个log模块,然后里面为了线程安全且多线程下不互相写乱,并且因为这些系统基本都用比较高版本的编译器,都支持C

libatbus 经过茫茫长时间的编写+过年在家无聊补充和修正单元测试,再加上这两天的整理,终于把以前的这个关于服务器通信中间件的基本功能和相应的单元测试完

小记最近踩得两个C++坑 记一下最近踩得两个C++独有的暗坑,其中一个和ABI相关。第二个坑其实之前研究过,但是没有实例,这次算是碰到了个典型

INI 配置读取库发布 Github地址: https://github.com/owent/libiniloader OSChina镜像: http://git.oschina.net/owent/libiniloader 项目中经常会碰到需要读取配置的情况,而用ini配置最大的优势就是简单易懂。 但是现在