背景 接上文 《大语言模型的基石:Transformer 入坑笔记(三) - 注意力机制和 Transformer》。 通过之前的内容,我们大致了解了大语言模型的基石:Transformer 的基础原理。 但随之而来有一个问题:随着参数量和上下文长度的增长,计算量太大扛不住了。 现在很多大语言模型,经过了多轮迭代,终于陆陆续续能在参数量持续提高的前提下同时支撑 1M 上下文。
阅读全文背景 接上文 《大语言模型的基石:Transformer 入坑笔记(二) - 基本原理和 Word Embeddings》,继续我们的 Attention Is All You Need/Transformer 学习之旅。 首先简单了解下传统的方案。 卷积神经网络(CNN) 卷积神经网络(CNN)似乎更适合静态数据(比如图片处理、提取特征等)。 所谓静态数据,是指每个数据组都单独和目标矩阵运算,通过卷积层、池化层、全连接层等输出。 每个数据组都单独运算所以可以大规模并发,但是数据组之间也缺乏关联。 我大概看了下原理,和我们要关注的 Transformer 关系不大,先略过了。
阅读全文背景 继续我们的 Attention Is All You Need 学习之旅。 我不是这个领域的,只是感兴趣想补一下基础,所以这一篇先只看最通用的原理:神经网络训练的大概流程、Embedding 是什么,以及 Word2Vec 里两种常见优化思路。 Attention Is All You Need 最早落在机器翻译任务上,它提出的核心架构就是 Transformer。工程上我们常接触到的 Transformers 库,则是围绕这类模型提供了更完整的封装。
阅读全文前言 这几年 AI 的热度一直很高。日常问答、写代码、整理文档、做工具,它已经开始进入不少人的日常工程流。我最近也开始认真补这块东西,主要是想搞清楚:这些模型到底是怎么一步步训练出来的,以及它有没有机会更深入地帮我们优化游戏研发里的工作流。
阅读全文背景 这两天 DeepSeek V4 Pro 刚上线,小米那边也送了一个月的 Mimo Token plan。我本来就在试着用 AI 做一个完整工具,正好顺手把几个国产大语言模型都拉进来跑了一轮:GLM 5.1、Kimi K2.6、Mimo v2.5 Pro 和 DeepSeek V4 Pro。 测试样本是我手头正在做的一个工具项目,后面只保留和模型表现有关的数据,不展开它自己的功能设计。
阅读全文背景 今年国产大模型是真的热闹。新模型一出来,宣传话术一个比一个猛。 尤其是最近出来的 GLM 5.1。 还有 Kimi K2.6。 海报和宣传图看着都很唬人,但真到自己拿去干活的时候,往往还是会闻到一点“跑分没输过,实战没稳过”的味道。所以我干脆把最近几个真实使用场景里的体验记了下来。
阅读全文
07前言 在上一篇文章中,介绍了 libatbus 从静态子网树到动态拓扑注册表的路由设计变更。新的拓扑模型解决了代理层无法弹性伸缩和跨区域隔离的问题,但路由只是底层基座——上层应用框架 libatapp 才是真正面对业务开发者的接口。 这篇文章聚焦于 libatapp 在新架构下的连接管理层设计,涵盖以下核心问题:
阅读全文前言 很久很久以前,我为了解决以前项目中bus通信膨胀的问题设计了 libatbus, 当时主要解决的核心问题是解决大量服务器节点互通时服务器间两两建立通道时的大量内存浪费问题。也同时使用跨进程的无锁队列避免了多写单读场景下的加锁以提高性能。
阅读全文背景 前段时间例行升级我为游戏框架写的构建系统 cmake-toolset 时,又遇到了 protobuf 的一个新 ABI 兼容性问题。 这已经不是第一次被 protobuf 的 ABI 兼容性问题“教育”了。这篇把问题拆开讲清楚,并给出一套可落地的规避方案,供遇到类似问题的同学参考。 编译环境:Windows + Visual Studio 2026 Abseil-Cpp:20250512.1 Protobuf:v31.1(看起来目前最新的 v33.1 也有这个问题) 现象与错误定位 首先在链接阶段出现错误:
阅读全文背景 在很久以前,我给我的Blog的主题加了 Hugo 的针对 Mermaid 和 Chart.js shortcodes 的支持。但是之支持迁入代码的方式。 如果文档很复杂,在Markdown里写大段的代码体验观感也不是很好。 而现在很多Markdown生态里是支持通过代码块的方式嵌入的。 同时现在很多插件可以直接按文件后缀编辑文件,然后直接指向文件的形式引用进来,这样可维护性会好很多。
阅读全文背景 近期,公司代理侧的流量负担持续上升;在高峰期访问常见开发资源(包管理器、SDK、依赖镜像、CDN 文件等)会出现明显抖动。为降低重复下载带来的外网带宽开销与峰值波动,决定在内网引入一套“通用下载缓存代理”。
阅读全文前言 现代化的C++项目可以借助多种静态分析工具来检查和发现潜在问题,包括空指针访问风险、未定义行为(UB)、内存错误等。 在我们的项目中,服务器工程基于 CMake 构建系统,可以方便地利用社区支持来集成这些静态分析工具,如 clang-tidy、clang-analyzer、CodeChecker 等。然而,另一部分 C++ 代码运行在 UE(Unreal Engine)引擎中。由于 UE 在编译流程上做了一些特殊扩展,再加上 UBT(UnrealBuildTool)工具在某些能力上的限制,直接开启静态分析会遇到一些问题:
阅读全文背景 在大型 UE(Unreal Engine)项目中,“模块/插件"是维持工程可维护性的基本手段。但随着工程规模增长,很容易出现循环依赖问题: 模块 A 为了复用工具函数依赖模块 B 模块 B 为了注册某些类型或访问某些资源又依赖模块 A 在某些平台或配置下(尤其是 Editor 构建或 Link 阶段需要聚合大量 .so/.a 时),最终表现为 循环依赖 UBT(UnrealBuildTool)能检测到循环依赖,但输出的是 ActionGraph 层面的信息:大量 Action #xxxx,并提示"这些 action 互相成环”。对于实际排障来说,主要痛点在于:
阅读全文背景 近期在给一个项目换一些底层接口的日志处理部分。把原始的类 printf 的格式化方式换成 fmtlib / C++ 20 Text Formatting 的方案。 然后发现,替换完一段未执行的代码后,会发生内存写坏的情况。 问题分析 通过跟踪生成的汇编和 gdb 的 info frame 位置。发现替换之后,栈帧位置大幅增加了。比如对这类代码:
阅读全文前言 近年来可观测性领域越来越成熟,游戏服务的可观测性能力建设日益成为提升产品质量与运维效率的关键环节。随着游戏系统架构的不断复杂化,传统的监控和故障排查方式已难以满足业务高可用和用户体验优化的需求。通过健全的可观测性体系,可以实现对游戏服务全链路的实时监控、异常检测与分析,助力技术团队及时发现和定位问题,推动产品持续优化与稳定迭代,从而为玩家提供更加流畅和可靠的游戏体验。
阅读全文前言 我给我们的服务器框架深度集成了一些可观测性的能力。使用 opentelemetry-cpp 作为接入层。 在指标方面,我们允许业务层自由地定制化指标上报和拉取,并以此实现策略控制。上报的时候有Pull模式接口(异步接口),也有Push模式接口(同步接口)。 为了减少 opentelemetry-cpp 内部的视图合并开销,性能最佳,我们尽量使用异步接口。 但是这种情况下由于 opentelemetry-cpp 内部存在后台Processor线程、Exporter线程等,指标的采集往往需要跨线程操作。 这就要求我们上报代码逻辑需要保证线程安全。
阅读全文背景 设计 《libcopp对C++20协程的接入和接口设计》 的时候,由于C++20协程的promise和awaitable是链式关联的。所以当时设计promise和awaitable之间通过一个共享的context来通信交互。当时第一版实现直接使用了 std::shared_ptr 来管理共享引用,也预留了个规划是未来可以改成非线程安全的引用来减少不必要的Cache Miss开销。
阅读全文背景 我们项目组需要接入多种RPC接入和工具转换流程,并且每种接入层有自己的扩展和定制需求。为了提高开发效率,我们需要一个通用的RPC代码生成器,能够支持多种RPC接入层级的代码生成,同时支持自定义插件和模板。并且自由增加自定义插件而不需要变更构建系统流程。以便提供最佳的灵活性且能支持protobuf的所有特性。
阅读全文背景 我们的新项目有个比较复杂的全区全服交易行系统,其中搜索和推荐是高实时性全区服多维度排序的,并且要支持比较复杂的标签交集查询和属性范围查询的自由组合。 当有订单发生变化时,它不仅仅会影响全服状态下搜索和推荐条件的结果变化,也会同时影响商品维度的聚合,交易行层面的数据聚合。
阅读全文前言 我们项目组前段时间排查和分析压测环境下的某些业务模块大量索引结构的内存问题。通用的工具比如 jemalloc+jeperf 或者 tcmalloc+gperf 的组合过于底层,一方面开启跟踪开销较高,另一方面也是会产生过多噪音数据影响判断。所以我针对我们的智能指针(包含 std::shared_ptr 和我最近写了个非线程安全的版本的 strong_rc_ptr , 这个后面有空再分享)和STL容器实现了allocator来帮助动态的手动插桩来分析问题。 最终的效果是可以通过一键替换类型申明的Allocator来插入动态控制和插桩统计的能力,这里分享一下手夯标准STL allocator的一些实现细节,方便其他小伙伴如果需要做…
阅读全文背景 这篇分享拖更了好久了。问题起源于去年我们项目组接入 opentelemetry-cpp 的时候,在进程优雅退出的时候偶现超时,虽然可以直接kill进程没啥影响但是退出不“优雅”的话总归会破坏发布流程,增加人工介入的成本。这里记录一下问题可能其他的组件有类似的用法也会有相似的问题。
阅读全文前言 近期发现项目组使用新版本的 opentelemetry-cpp 的时候偶现崩溃。崩溃的位置在STL的 std::future 析构的地方,而这个 std::future 由 std::async创建。 比较违反直觉,这里记录分享一下分析和解决过程方面其他碰到的小伙伴们。 问题分析 相关代码和规范 首先我们来看下相关代码:
阅读全文背景 早先社区报过 opentelemetry-cpp 在GCC 14中编译不通过的问题。最近我也是先升级我们项目组的工具链,主要也是把GCC升级到GCC 14,这时候发现有些第三方工具构建失败。 这里记录一下以防后续其他人碰到参考。 分析 我们在使用新版本GCC 14编译zsh的时候,报 boolcodes 和定义冲突。
阅读全文前言 xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。 主要功能特点: 跨平台(java 11 or upper) Excel => protobuf/msgpack/lua/javascript/json/xml 完整支持协议结构,包括嵌套结构和数组嵌套 同时支持protobuf proto v2 和 proto v3 支持导出proto枚举值到lua/javascript代码和json/xml数据 支持导出proto描述信息值到lua/javascript代码和json/xml数据(支持自定义插件,方便用户根据proto描述自…
阅读全文前言 opentelemetry-cpp 在标准上报协议OTLP里是支持使用 gRPC 作为传输协议的。但是,当 gRPC 被作为静态库同时链接进多个动态库时,在一些平台上会有一些问题。这是 gRPC 本身的一些实现方式导致的。 一直拖到今天才来比较完整得写这个问题的具体成因和解决方案,实际上也有一些其他库有相似实现的也会有相同的问题,所以分享出来看看有没有其他同学也可能碰到可以参考一下。
阅读全文前言 xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。 主要功能特点: 跨平台(java 11 or upper) Excel => protobuf/msgpack/lua/javascript/json/xml 完整支持协议结构,包括嵌套结构和数组嵌套 同时支持protobuf proto v2 和 proto v3 支持导出proto枚举值到lua/javascript代码和json/xml数据 支持导出proto描述信息值到lua/javascript代码和json/xml数据(支持自定义插件,方便用户根据proto描述自…
阅读全文前言 近期的 protobuf v22和 gRPC v1.55 版本在构建流程层面引入了一些比较大的变化。 最初我关注到这个问题是在我参与的一个社区项目 opentelemetry-cpp 的issue中( https://github.com/open-telemetry/opentelemetry-cpp/issues/2095 )。 直到后来,我们在自己的构建系统 cmake-toolset 对 protobuf 和 gRPC 也进行了升级。所以顺带给社区的项目也提交了一些相关的Patch,在这里分享一下可能其他同学也会碰到。
阅读全文前言 年初的时候我们项目组的构建系统( cmake-toolset )里把 protobuf 升级到了 v20/v3.20 版本, gRPC 也升级到了 v1.54 版本。然而这两个版本在Linux的ELF ABI和MacOS的Macho ABI下都出现了一些符号未定义的问题(当然也包含Android和iOS)。 这些问题也不仅限于 protobuf v20/v3.20 和 gRPC v1.54,后续的版本有些修复了,有些没有。在官方完全修复之前,我们自己打了一些patch去修复这些问题。
阅读全文前言 xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。 主要功能特点: 跨平台(java 11 or upper) Excel => protobuf/msgpack/lua/javascript/json/xml 完整支持协议结构,包括嵌套结构和数组嵌套 同时支持protobuf proto v2 和 proto v3 支持导出proto枚举值到lua/javascript代码和json/xml数据 支持导出proto描述信息值到lua/javascript代码和json/xml数据(支持自定义插件,方便用户根据proto描述自…
阅读全文前言 我们终于在年初的时候最后完成了整体服务器框架对C++20协程的支持和接入。虽然之前陆陆续续抽时间改造一些组件,让它支持C++20协程,期间也记录了一些早期的设计思路和踩的坑(包括 《libcopp接入C++20 Coroutine和一些过渡期的设计》和《libcopp对C++20协程的接入和接口设计》),其中不乏一些C++20协程使用上可能打破我们常规思路细节和编译器的BUG。而且这些都是各个组件的改造,并没有最后整合到一起。
阅读全文背景 Opentelemetry-cpp 是可观测领域,opentelemetry (CNCF基金会孵化项目)的C++ SDK接入层。 opentelemetry 里面主要是分链路跟踪(Trace)、指标(Metrics)、日志(Logs)三大块。 同时 opentelemetry 有一个标准规范文档 opentelemetry-specification ,而SDK实现主要就是来对这个标准规范文档的特定语言实现。 由于日志(Logs)这一块一直处于Experimental阶段,所以很长时间以来 C++ SDK接入层 都没有及时更新跟进规范的变化。
阅读全文前言 前段时间集成一些公司内组件的时候发现它依赖 nghttp2 。正好之前一直有给我的构建工具(cmake-toolset)里的构建 curl 的流程加 HTTP/2 和 HTTP/3 的计划。 所以这波一次性搞定了。 构建工具 cmake-toolset 和 curl 首先,curl 是支持多种第三方库作为 HTTP/2 和 HTTP/3(QUIC)算法库的。比如 nghttp3+ngtcp2,或者微软家 msquic,或者Google家 quiche。 其中HTTP/3只能选一个,互相是冲突的。而Google的quiche官方仅有对bazel构建系统的支持,而我的cmake-toolset是cmake生态的。 这里选用 ngh…
阅读全文背景 传说中的下一代 iptables 的 nftables 已经出来了好长时间了。现在主流发行版的内核也都已经更新到了对 nftables 支持足够好的版本。 在2年多前我也初步体验过了 nftables ,当时写了个 《nftables初体验》 。并且开始使用 nftables 来实现对家里软路由的管理。 而去年的时候,我也尝试用 nftables 实现了双拨(详见: 《折腾一下nftables下的双拨》)并且可以搭配TPROXY透明代理使用。
阅读全文前言 前段时间有人在 opentelemetry-cpp 提出了api组件在动态库中单例无法工作的 issue ,( https://github.com/open-telemetry/opentelemetry-cpp/issues/1520 ) 。 opentelemetry 是可观测性领域的开源项目,目标是统一链路跟踪、数据指标和日志的服务、上报、协议和接口规范,目前属于 CNCF基金会 孵化项目。而 opentelemetry-cpp 则是 opentelemetry 中对标准规范SDK的C++实现。
阅读全文前言 xresloader 是一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript、UE-Csv、UE-Json等数据格式的工具。 并且整个工具链还包含了基于模板引起生成读表代码的 xres-code-generator ,方便产品/策划使用的 GUI批量执行工具 - xresconv-gui 和方便CI集成和程序使用的 命令行批量执行工具 - xresconv-cli。
阅读全文前言 最近新项目重新评估了一下protobuf的C/C++ -> Lua binding 方案。之前,使用最广泛的 Lua binding 方案应该是 云风 的 pbc 。但是这个库已经是作者弃坑好多年的状态了。我之前使用 pbc 的时候刚碰上 protobuf 3.0 刚出来,当时打了patch来适配 protobuf 3.0 ,还修复了一些其他问题。这个Patch有些推给了上游,有些因为和上游的某些机制冲突没有推。我了解到的很多其他项目也或多或少的打了自己的Patch,大多数也没往上游推。基本上 pbc 已经处于一个失维的状态,所以这次新项目就干脆来寻求更好,或者说仍然有良好活跃度的解决方案。于是就看向了 upb 。
阅读全文前言 最近开的坑有点多。有点忙不过来了所以好久没写Blog了。这个C++20的协程接入一直在改造计划中,但是一直没抽出时间来正式实施。 在之前,我写过一个初版的C++20协程接入 《libcopp接入C++20 Coroutine和一些过渡期的设计》 。当时主要是考虑到 Rust也有和C++类似的历史包袱问题,所以参考了一些Rust协程改造过程中的设计。 但是后来尝试在项目中使用的时候发现还是有一些问题。首先C++20的协程并不是零开销抽象,所以强行用Rust的模式反而带来了一定开销和理解上的难度。其次原先的设计中 generator 是按类型去实现外部接入的。但是实际接入SDK的过程中我们有相当一部分类型相同但是接入流程不同的情况…
阅读全文前言 一直以来,我都维护了完整的 GCC 工具链构建工具 和 LLVM,Clang,libc++,libc++abi工具链构建工具 。 一方面是为了测试和体验新版本编译器的功能和利用一些更现代化的工具检查代码中的风险,另一方面也是为了给我得很多开源仓库做多版本适配。 其中所有的编译期依赖项(不包括 tar,awk等可执行程序的工具)都是自己构建的,这样也能管理好某些新版本组件需要的新版本依赖项,并且做到跨发行版兼容。同时很多发行版自带的 LLVM+Clang 套件都缺斤少两,有的缺少 clang-analyzer ,有的缺少 clang-format ,也有的缺少 libc++ 和 libc++abi 或者缺少sanitizer组件…
阅读全文前言 接上文 《游戏服务的分布式事务优化(一)- Write Ahead Log(WAL) 模块》 在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制,以优化好友和公会服务的一致性流程。 最开始的实现并不通用,后来我对这个事务的实现做了进一步的优化和重构,抽离成了较为通用的模块,并对之前没全部完成的功能做了进一步完善。 此篇为重构内容的第二部分,主要聚焦于事务管理。
阅读全文前言 在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制,以优化好友和公会服务的一致性流程。 但是时间原因,但是写的第一版是深入我们当时的游戏业务的,第一版仅用在好友服上,既不通用测试也不完善。 后来逐渐把公会服务和聊天的功能也采用或部分采用这里的分布式事务的组件来实现,发现有大量的相似代码。 并且由于分布式事务的流程本身比较复杂,其他人接手的时候看起来就会比较吃力,所以我一直有计划重构这一块代码并且实现为更加通用且灵活的模块。 最近也是基本完成了这部分的工作,通用接口主要分为两部分。第一部分是 Write Ahead Log(WAL) 模块,第二部分是事务管理模块…
阅读全文之前搞 opentelemetry-cpp 的时候接触了下 bazel 构建系统。这玩意儿用起来有一点坑,特别是使用自定义编译环境的时候。 在使用我自己编译的很新版本的 GCC 和 clang+libc++ 的时候,涉及对libssp的检测和 LD_LIBRARY_PATH 环境变量在 bazel 中各个步骤中的传递,这里记录一下适配脚本。
阅读全文前言 很久很久以前,浮点数的性能和跨平台跨硬件架构一致性是无法获得保证的,所以我们一般在需要强一致性和高性能的游戏服务器中会禁用浮点数,转而使用自己实现的定点数。 这么多年过去了,前段时间想看看现代化硬件下是否仍然有性能问题和是否能够保证一致性,做了些简单的测试,这里记录一下。
阅读全文前言 openssl 3.0发布好一阵子了,我的 atframe_utils 其实也挺早前就完成了对 openssl 3.0 和 boringssl 的适配。但是由于懒,一直没写这篇文章。在升级 [openssl] 3.0 和 boringssl 还是碰到了一些问题的,有些是由于接口变化,有些是由于功能支持还有些也和构建系统相关。还是有必要记录一下,至少能方便以后查找。
阅读全文前言 偷懒了好久没有写分享了,最近的时间也是花费了很多时间大量优化了之前游戏服务器框架和组件的很多细节。其中,相对独立且同时也被其他的项目使用的一个工具则是基于 cmake 和 git 且兼容 vcpkg 的构建系统 cmake-toolset 。之所以要写这么个构建工具主要是要提供比 vcpkg 更宽容的兼容性(没办法我们公司的编译环境比较古老),并且提供更进一步的定制化能力(包含但不限于功能开关和下载源,这些东西 vcpkg 也是很后期才有了个初步的支持)。那么先来记录一下构建系统适配过程中的一些问题吧。
阅读全文前言 C++20 正式发布已经有一段时间了。其中 Text Formatting 是一个我个人比较感兴趣的新组件。它主要是解决了之前字符串格式化库 ( printf 系 ) 的效率问题和运行时安全的问题。 并且新的格式设置的形式也比较友好。相关规范和用法可以参见: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0645r10.html#format.formatter http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2216r3.html https://en.cppreference.com/w/c…
阅读全文背景 我们有时候写一些基础性类库或者实验新功能的时候,常常需要使用到最新版本的GCC和Clang。一些Linux发行版的源里和一些工具链(比如MSYS2)里其实自带LLVM套件的包,LLVM 官网也提供一些常见平台的预编译包下载。 那为什么我们还要自己编译呢?如果有注意到的小伙伴可能会发现,很多平台的源和 LLVM 官网 里下载的预编译包,其实是缺失很多组件的。有些没有libc++和libc++abi(CentOS 8),有些没有Sanitizer相关的组件,有些缺失其他的组件。而Clang虽然支持GCC的libstdc++,但是一方面我们写基础性类库还是要优先考虑原生STL库的兼容性,另一方面Clang对libstdc++的支持也…
阅读全文背景 对大型项目来说,必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言,依赖管理一直是一个比较头大的问题。 很多老式的系统和工具都会尝试去走相对标准化的安装过程,比如说用 pkg-config 或者用系统自带的包管理工具装在系统默认路径里。 当然这样很不方便,也不容易定制组件。我使用 cmake 比较多,所以一直以来在我的 atframework 项目集中有一个 utility 项目 atframe_utils,里面包含一些常用的构建脚本。 并且在 atsf4g-co 中实现了一些简单的包管理和构建流程。
阅读全文可能是疫情的原因,GCC好久没发布啦。最近总于又Release了,还是大版本。并且三大编译器对C++20的支持也都七七八八了。所以特意立贴庆祝一下,顺带更新一波构建脚本把这两年的一些改动列举一下。 GCC编译 构建脚本的主要变化如下:
阅读全文背景 我们小区终于有联通线路啦,之前一直用的联通的手机号。它套餐满一定额度以后送一条宽带,本着不用白不用的精神,那必须不能浪费。还好我之前设置软路由得时候就预留了两个网口作wan,所以新增得联通得线路直接插那个口上就行了。(吐槽一下联通给得光猫竟然是8年前生产的老古董)
阅读全文C++20 开始支持 Module 了。在以前C++为了解决循环依赖问题,经常会把类或者函数声明写前面,实现写后面。然后中间的代码就可以实现内部模块的内聚而互相引用。比如: class foo; void bar(foo*); class foo { public: foo(){ bar(this); } }; 那么在 Module 里怎么处理这种需求呢?其实我之前一直只是知道有这么个东西,并没有深入研究过。前段时间看到公司论坛里有同学问,就现学了并且试了一下,以下是一些记录。
阅读全文