宏生成代码的难点开源代码中如何解决的一、实现宏动态调用多次二、实现动态选择宏名称三、其他实现细节应用与实践——json解析1. 功能更新与效率优化2. 利用宏简化代码3. 性能测试3.1 如何在cmake工程中引入测试框架 单元测试使用的gtest，benchmark用的简单的nanobench。3.1.1 引入gtest gtest引入cmake只需要如下代码：cmake_minimum_required(VERSION 3.14) project(my_project) # GoogleTest requires at least C++14 set(CMAKE_CXX_STANDARD 14) include(FetchContent) FetchContent_Declare( googletest URL https://github.com/google/googletest/archive/03597a01ee50ed33e9dfd640b249b4be3799d395.zip ) # For Windows: Prevent overriding the parent project's compiler/linker settings set(gtest_force_shared_crt ON CACHE BOOL "" FORCE) FetchContent_MakeAvailable(googletest) 在使用时还要注意链接 gtest_main，如 target_link_libraries(unittest PRIVATE gtest_main)。 更多使用请查看官方文档：google.github.io/googletest/quickstart-cmake.html3.1.2 引入nanobench nanobench引入cmake也只需要如下代码，由于nanobench是head-only的，你也可以直接拿到 .h 文件便可以得到所有功能了。FetchContent_Declare( nanobench GIT_REPOSITORY https://github.com/martinus/nanobench.git GIT_TAG v4.1.0 GIT_SHALLOW TRUE) FetchContent_MakeAvailable(nanobench) add_executable(MyExample my_example.cpp) target_link_libraries(MyExample PRIVATE nanobench) 简单使用如下：#include <nanobench.h> #include <atomic> int main() { int y = 0; std::atomic<int> x(0); ankerl::nanobench::Bench().run("compare_exchange_strong", [&] { x.compare_exchange_strong(y, 0); }); } 更多使用请查看官方文档：nanobench.ankerl.com/tutorial.html3.2 性能测试的结果 通过解析同一个 json 文件(2500多行)来测试各自的解析性能（不包含文件IO）。 通过重新反序列化为 json 串，然后写入文件来测试正确性以及反序列化的性能（不包含文件IO）。 具体代码在： 最终结果如下图： img1 上图为第一次bench的结果，基准测试表明，yazi-json的结果是最不稳定的，之前自己简单跑跑稳定性还没表现的这么差，现在benchmark测完后发现性能确实是比较差劲，都和深拷贝的 nlohmann和jsoncpp一个水平线了，稳定性还不如他们，这种情况我之前就有所预料，因为里面申请内存的次数太过频繁了。话说回来，我测试的这几个json库，rapidjson和其他所有的库直接不在同一水平线上了。 然后我又benchmark了一次，耗费我两三分钟终于跑完了，这次表现各个json库的表现如下： bench2 具体表现和上一次还是大差不差。 总结上述基准测试的结果，可以得出以下结论：把string全面换成string_view确实得到了不俗的性能提升，我的json库的解析性能已经高于 nlohmann 和jsoncpp了。转json字符串的性能比较弱，原因是完全没有做任何优化，纯在用stringstream进行字符串的输出，后面有时间会想着优化一下，至于为什么比yazi那个快一点，那纯纯是因为yazi那个里面存的还是string使用stringstream进行输出时总会比string_view多一次拷贝。rapid-json的速度还是…