C-Cpp

一、相机预处理是怎么拖垮检测的做智能摄像头、机器人视觉的人几乎都踩过同一个坑:摄像头采集的 YUV 数据哗啦啦地进来,你的检测模型嗷嗷待哺地等着 RGB 输入,中间还得做缩放、裁剪、旋转。 你一开始图省事,用 OpenCV 的 cvtColor + resize 在 CPU 上跑。结果画面一复杂、分辨率一高,CPU 占用直接飙到七八十,帧率掉得惨不忍睹,整个板子热得能煎鸡蛋。 这就是典型的「CPU 预处理瓶颈」:算法本身还没发力,数据搬运和格式转换就把系统拖垮了。问题根子在——YUV 转 RGB、缩放、裁剪这些 2D 图像操作,根本不该占用通用 CPU 的算力。 以 Rockchip RK3588 上一块四路 1080P 智能门禁为例:每路都要把 NV12 格式的 YUV 流实时转成 RGB,并缩放到模型要的 300×300。纯 CPU 方案下,四核 A76 全开、占用率接近 100%,帧率勉强 15 帧,延迟肉眼可见。 二、RGA 是什么:Rockchip 的 2D 图像加速单元这时候,RK3588 内置的一个「神器」该登场了——RGA(Raster Graphic Accel...

本文灵感来源于知乎专栏文章《最后的绅士》 一、一条刻在肌肉记忆里的铁律作为一个 C++ 工程师，我相信很多人和我一样，脑子里都刻着一条铁律： "传参用 const&，拷贝贵。" 这条规则在很多场景下确实是正确的。当函数只是观察参数，不作任何修改时，使用 const& 可以避免不必要的拷贝： 1234567double norm(std::vector<double> const& xs) { double sum = 0.0; for (double x : xs) { sum += x * x; } return std::sqrt(sum);} 这个函数只是读取向量的元素，不会修改它。使用 const& 是完全合理的选择。 但是，这条铁律在一种场景下会完全失效——当函数的工作是转发参数的时候。 二、const& 毁掉一切的场景让我们来看一个看似人畜无害的包装类： 12345678910template <clas...

一、一行「看似无用」的空代码先来看一段真实项目中的代码——它出现在一个嵌入式 CAN 总线通信模块的断线重连逻辑里： 1234567void CANTransport::close() { _autoReconnect.store(false); { std::lock_guard<std::mutex> lk(_reconnectMutex); } _reconnectCond.notify_all();} 初看这段代码，那个孤零零的花括号块让人困惑：lk 刚构造完就被析构了，花括号里面什么也没干，这不就是一段空操作吗？直接把锁删掉，写成下面这样不是更简洁？ 123// 很多人会这样"优化"——但这埋下了定时炸弹_autoReconnect.store(false);_reconnectCond.notify_all(); 这两行代码的区别，正是 C++ 多线程编程中最隐蔽的陷阱之一——Lost Wakeup（丢失唤醒）。今天我们就来把它的原理讲透。 二、条件变量的...

一、从角色模糊到分工明确：RSTP 端口角色的革命在上一篇文章中，我们提到 STP 只有两种端口角色：根端口（Root Port）和指定端口（Designated Port）。这种二分法在面对复杂拓扑时显得力不从心——一个端口如果既不是根端口也不是指定端口，就只是一个"被阻塞的端口"，交换机不知道这个阻塞端口在拓扑变化时能起到什么作用。 RSTP 将端口角色扩展为四种： 12345RSTP 端口角色├── Root Port（根端口） — 非根桥上离根最近的端口├── Designated Port（指定端口） — 每条链路上离根最近的端口├── Alternate Port（替代端口） — 根端口的"备胎"└── Backup Port（备份端口） — 指定端口的"备胎" 1.1 Alternate 端口：根端口的快速后备Alternate 端口是 RSTP 最重要的新增角色。它的定义是：收到了来自其他交换机的更优 BPDU，但不如当前根端口优的端口。 用一个通俗的类比： 根端口是你...

一、网络冗余的"双刃剑"在一个可靠的网络中，冗余链路是必不可少的。想象一个企业园区网：核心交换机与汇聚交换机之间通常会有两条甚至多条物理链路相连，目的是当其中一条链路发生故障时，流量可以自动切换到备用链路，保证业务不中断。 然而，冗余链路带来了一个致命的问题——二层环路。 1234 [SW1] / \ / \[SW2]---[SW3] 在以太网帧的头部，没有 TTL（Time To Live）字段。IP 数据包有 TTL 来防止无限循环，但二层以太网帧一旦进入环路，就会永无止境地被转发。这就是广播风暴的根源。 环路带来的三大危害： 问题 描述 后果 广播风暴 广播帧在环路中无限复制转发 带宽被耗尽，网络瘫痪 MAC 地址表震荡 同一 MAC 地址在交换机不同端口间反复翻转 交换机无法正确转发单播帧 重复帧 同一数据帧通过不同路径多次到达目的地 上层协议可能出错 正是为了解决这个矛盾——在保留冗余链路的同时消除环路，**生成树协议（Spanning Tree Protocol, STP）**应运而生。 二、传统 S...

如果你曾写过这样的代码—— 12345678910Result process(Request req) { req = validate(req); if (!req.valid) return error; req = enrich(req); req = transform(req); req = filterFields(req); saveToDB(req); sendNotification(req); return success;} ——你一定感受过它的问题：函数体越来越长、每个步骤紧耦合、加一步就要改主流程、单元测试只能测整体。 Pipeline 模式就是为这种"多步骤顺序处理"场景而生的。它把每一步封装成独立的阶段（Stage），数据像流水线一样在阶段之间传递——每个阶段只做一件事，且只关心自己的输入和输出。 一、什么是 Pipeline 模式1.1 核心思想Pipeline 模式将复杂处理流程拆解为一系列独立的阶段（Stage），每个阶段接收数据、加工数据、输出数据，阶...

你改了一行日志格式，然后等了 45 分钟——编译 18 分钟、单测 12 分钟、镜像构建 10 分钟、滚动发布 5 分钟。等新版本上线后，日志显示一切正常。但你忍不住想：我为什么要为一行日志重启整个服务？ 静态编译的痛苦在于它的"原子性"：哪怕只改一行代码，也要重新经历完整的构建-测试-部署链条。随着项目规模膨胀到百万行级别，这个链条会变得越来越难以忍受。 如果每个模块都是一个独立的动态链接库（.so / .dll / .dylib），可以被主程序在运行时加载、卸载、替换——会怎样？ 这就是基于动态库的"热插拔"架构。 一、核心思想：动态库即插件1.1 从静态到动态的思维转变1234567891011121314151617静态编译模型：┌──────────────────────────────┐│ main.cpp ││ + module_a.cpp (静态链接) ││ + module_b.cpp (静态链接) │ → 一个庞大的二进制文件│ + mo...

假设你正在写一个量化交易系统。行情数据以每秒百万次的速度涌来，你的策略引擎需要在微秒级做出响应——同时系统还必须支持用户上传自定义策略脚本，而这些脚本里可能藏着死循环、空指针，甚至恶意的系统调用。 多进程？IPC 延迟在毫秒级，会把你的策略延迟拖慢三个数量级。直接多线程？一个用户的野指针就能把整个交易引擎拖垮。 有没有第三条路——兼具多进程的隔离性和多线程的性能？ 有。这就是基于线程池的沙箱隔离架构。 一、背景：两条传统路径的死胡同1.1 多进程架构：安全但臃肿123456789┌──────────┐ ┌──────────┐ ┌──────────┐│ Plugin A │ │ Plugin B │ │ Plugin C ││ (进程) │ │ (进程) │ │ (进程) │└────┬─────┘ └────┬─────┘ └────┬─────┘ │ IPC │ IPC │ IPC └──────────────┼─────────────┘ ┌─────┴────...

想象一个典型的移动端场景：运营团队策划了一个限时营销弹窗，需要在几小时内上线。而完整的原生发版流程——代码开发、测试、打包、提审、应用商店审核——往往需要一到两周。当这个弹窗终于通过审核上线时，活动可能已经结束了。 这不是某一个团队能解决的问题，而是移动互联网行业的结构性困境：原生发版的节奏，已经跟不上业务迭代的心跳。很多开发者对此深有体会——作者本人曾在制造企业的内部 OA 系统研发中，也经历过这种"改一行文案需要重新打包分发"的无奈。 如何让一个 App 同时做到"核心体验极致流畅"和"边缘业务小时级上线"？这就是混合架构要回答的问题。 一、痛点：发版周期的结构性矛盾1.1 两组互相撕裂的数字 维度 原生发版 业务诉求 典型周期 2 周（含审核） 小时级 大促场景 需要提前一个月封版 临时策略随时调整 紧急修复 审核排队 1-7 天 分钟级止损 灰度能力 依赖商店百分比放量 需要按用户画像精准投放 这两组数字的冲突，本质上是 "静态二进制分发"与"动态业务运营&...

C++23新特性解析：现代C++的进一步完善C++23是对C++20的重要补充和完善，引入了许多实用特性，使得代码更加简洁、安全和可维护。本文将解析C++23的核心特性，包括语法示例和使用场景。 一、显式对象参数（Explicit Object Parameters）C++20的限制： 12345678// C++20中，成员函数的this指针是隐式的class MyClass {public: void method() { // this是隐式参数 std::cout << "this = " << this << std::endl; }}; C++23的改进： 123456789101112131415161718// C++23中，可以显式声明this参数class MyClass {public: // 显式对象参数 void method(this MyClass& self) { ...

C++20新特性解析：现代C++的重大突破C++20是C++标准的重大更新，引入了许多革命性的特性，包括概念、范围、协程、模块等。本文将解析C++20的核心特性，包括语法示例和使用场景。 一、概念（Concepts）：类型约束的革命C++17的限制： 12345678// C++17中，使用SFINAE或static_assert进行类型约束template<typename T>auto add(T a, T b) -> decltype(a + b) { return a + b;}// 问题：错误信息不友好// 当传入不支持+操作的类型时，错误信息复杂 C++20的改进： 1234567891011121314151617181920212223242526#include <concepts>// 定义概念template<typename T>concept Addable = requires(T a, T b) { { a + b } -> std::sa...

C++17新特性解析：实用性增强C++17引入了许多实用性特性，让代码更加简洁和安全，被称为"C++的实用主义更新"。本文将解析C++17的核心特性，包括语法示例和使用场景。 一、结构化绑定：简化变量声明C++11/14的限制： 12345678910111213141516// C++11/14中，需要单独声明变量std::pair<int, std::string> p = {1, "hello"};int id = p.first;std::string name = p.second;// 数组int arr[3] = {1, 2, 3};int a = arr[0];int b = arr[1];int c = arr[2];// 结构体struct Point { int x, y; };Point pt = {10, 20};int x = pt.x;int y = pt.y; C++17的改进： 1234567891011...

C++14新特性解析：现代C++的完善C++14是C++11的后续版本，主要对C++11进行了完善和扩展，引入了更多实用特性，使得代码更加简洁和灵活。本文将解析C++14的核心特性，包括语法示例和使用场景。 一、泛型Lambda表达式C++11的限制： 123// C++11中，Lambda参数必须指定类型auto add = [](int a, int b) { return a + b; };auto add_double = [](double a, double b) { return a + b; }; C++14的改进： 1234567// C++14中，Lambda参数可以使用autoauto add = [](auto a, auto b) { return a + b; };// 使用std::cout << add(1, 2) << std::endl; // 3std::cout << add(1.5, 2.5) << std::endl;...

在C++编程中，静态局部变量是一个常见但容易被忽视的线程安全问题来源。本文将深入分析静态局部变量在多线程环境下的行为、潜在问题以及解决方案。 一、静态局部变量的基本特性1. 什么是静态局部变量静态局部变量是在函数内部声明的static关键字修饰的变量，它具有以下特点： 123456789101112void func() { static int counter = 0; // 静态局部变量 counter++; printf("Counter: %d\n", counter);}int main() { func(); // Counter: 1 func(); // Counter: 2 func(); // Counter: 3 return 0;} 2. 静态局部变量的存储特性 生命周期：程序启动时分配，程序结束时释放 作用域：仅在声明的函数内部可见 初始化：仅在第一次调用时执行初始化，之后保持上次值 123456789// 静态局部变量的初始化时机void ...

C++11新特性解析：现代C++的起点C++11是现代C++的转折点，引入了大量革命性的特性，被业界称为"C++复兴"。本文将解析C++11的核心特性，包括语法示例和使用场景。 一、auto 和 decltype：类型推导的革命auto 关键字基本语法： 123456789// 自动推导类型auto i = 42; // intauto d = 3.14; // doubleauto s = "hello"; // const char*auto v = vector<int>(); // std::vector<int>// 与引用和const结合const auto& cr = i; // const int&auto& r = i; // int& 使用场景： 复杂类型：当类型名称很长时，auto可以简化代码 1234// 简化复杂类型std::map<std::string, std::vect...

在C++智能指针中，std::unique_ptr是一种独占所有权的智能指针，它确保同一时间只有一个unique_ptr实例拥有对对象的所有权。本文将深入分析unique_ptr的所有权转移机制以及各种相关场景下的行为。 一、unique_ptr的基本特性std::unique_ptr的核心特性： 独占所有权：同一时间只能有一个unique_ptr指向同一个对象 不可复制：禁止拷贝构造和拷贝赋值操作 可移动：支持移动构造和移动赋值操作 自动管理：当unique_ptr生命周期结束时，自动释放所管理的对象 二、unique_ptr转移给另一个unique_ptr的情况当将一个unique_ptr转移给另一个unique_ptr时，会发生所有权的转移。这可以通过以下方式实现： 1. 使用std::move()进行转移1234567891011121314151617181920212223242526272829303132#include <memory>#include <iostream>class MyClass {public: ...

在C++内存管理中，智能指针是一种重要的RAII（资源获取即初始化）机制，它能够自动管理动态分配的内存，避免内存泄漏。其中，std::shared_ptr是最常用的智能指针之一，而std::make_shared则是创建shared_ptr的推荐方式。本文将深入分析std::shared_ptr、make_shared与make_shared(new T)之间的关联、管理特点以及性能比较。 一、核心概念解析1. std::shared_ptr：引用计数的智能指针std::shared_ptr是C++11引入的共享所有权智能指针，其核心特性是： 引用计数：内部维护一个引用计数器，记录有多少个shared_ptr实例指向同一个对象； 自动析构：当引用计数降为0时，自动释放所管理的对象； 共享所有权：多个shared_ptr可以同时拥有同一个对象的所有权； 线程安全：引用计数的操作是线程安全的，但对象的访问需要手动同步。 2. std::make_shared：创建shared_ptr的推荐方式std::make_shared是一个模板函数，用于创建shared_ptr实例，其核心...

在多线程编程中，数据竞争和内存可见性问题是永恒的痛点。尤其是涉及到共享资源的读写分离场景，如何保证数据访问的安全性和一致性，往往是开发者需要重点攻克的难题。 一、先看核心代码我们今天的主角是这样一段代码，它在多线程回调系统中十分常见： 12std::atomic_store(&_callback_map_snapshot, std::shared_ptr<const CallbackMap>{}); 初看之下，这行代码似乎只是简单地给一个变量赋值为空，但背后却蕴含着多线程安全的设计思想。接下来我们逐部分拆解，搞懂它的每一个细节。 二、核心组件深度解析要理解这段代码，首先需要明确三个关键组件的作用和特性：std::atomic_store、_callback_map_snapshot 和 std::shared_ptr<const CallbackMap>。 1. std::atomic_store：原子赋值的"安全卫士"在多线程环境中，普通变量的赋值操作并非原子的。例如，一...

在C++面向对象编程中，静态成员函数是一个高频使用但容易混淆的特性——它不属于某个对象，而是属于整个类，这就导致很多开发者疑惑：静态成员函数到底能不能使用类的数据成员？该怎么用？ 本文将从底层原理出发，结合实战案例，彻底讲清静态成员函数与类数据成员的使用规则、场景及注意事项。 一、核心前提：静态成员函数的本质特性要理解静态成员函数对数据成员的访问规则，首先要明确它的核心特性： 无隐含this指针：普通成员函数会隐含一个this指针，指向当前调用该函数的对象，因此能直接访问对象的非静态数据成员；而静态成员函数属于“类级别的函数”，不依赖任何对象实例，所以没有this指针。 生命周期独立：静态成员函数在程序启动时（类加载阶段）就已存在，而非静态数据成员需要随对象创建才分配内存。 访问权限限制：静态成员函数只能直接访问类的静态数据成员，无法直接访问非静态数据成员——这是由“无this指针”和“生命周期不匹配”共同决定的。 简单总结：静态成员函数 ↔ 静态数据成员 可直接交互；静态成员函数 ↔ 非静态数据成员 需间接访问。 二、场景1：直接访问静态数据成员（最常用）静态数据成员同样属...

在网络通信、分布式系统、数据标识等场景中，sequenceNumber（序列号）是一个高频出现的核心元素。一个高质量的序列号生成方案需要满足随机性、唯一性（在一定范围内）、高性能等特性。 一、核心代码解析先看这段核心代码： 1234567891011121314#include <random>#include <cstdint>// 假设m_seqNum是类成员变量，类型为uint32_tuint32_t m_seqNum;void generateSequenceNumber(uint64_t seed) { // 初始化随机数生成器 std::mt19937 rng(seed); // 定义随机数分布：1 ~ UINT32_MAX（4294967295） std::uniform_int_distribution<uint32_t> dist(1, UINT32_MAX); // 生成随机sequenceNumber m_seqNum = dist(rng);} 这几行代码看似简单...

在 C++11 之前，实现异步任务往往需要手动管理线程（std::thread）、同步原语（std::mutex、std::condition_variable），不仅代码繁琐，还容易出现线程泄漏、死锁等问题。C++11 引入的 std::async 彻底改变了这一现状——它是高层异步编程接口，能轻松创建异步任务并获取结果，无需手动管理线程生命周期，是异步编程的“瑞士军刀”。 本文将从 核心概念、使用场景、参数详解、返回值处理、常见陷阱 五个维度，带你彻底掌握 std::async。 一、核心概念：std::async 是什么？std::async 是 <future> 头文件中的函数模板，作用是 启动一个异步任务，并返回一个 std::future 对象。核心特点： 异步执行：任务可能在新线程中执行，也可能在调用 get()/wait() 时同步执行（取决于启动策略）； 结果获取：通过返回的 std::future 对象获取任务执行结果（或异常）； 线程管理：由标准库管理线程（如线程池复用），无需手动 join() 或 detach()，避免线程泄漏。 ...

在开发脚本引擎或配置解析工具时，我们经常需要处理多种类型的语句（赋值、条件、循环等）。本文将通过一个实用的语句解析器案例，展示如何用注册式工厂模式构建易于扩展的解析系统。 一、需求分析与设计思路我们需要开发一个支持以下语句类型的解析器： 赋值语句（如x = 100） 条件语句（如if x > 5） 循环语句（如for i in 0..10） 核心挑战是：当需要支持新语句类型时，无需修改现有解析逻辑，只需添加新的解析器实现。这正是工厂模式的用武之地。 整体设计方案： 定义抽象解析器接口（基类） 为每种语句实现具体解析器（派生类） 用注册式工厂管理解析器的创建 通过语句特征自动匹配对应的解析器 二、核心代码实现1. 抽象解析器接口首先定义所有解析器的公共接口： 12345678910111213#include <string>// 语句解析器基类class StatementParser {public: virtual ~StatementParser() = default; // 解析语句（提取关键信息）...

在软件开发中，工厂模式是解耦对象创建与使用的经典方案。但传统工厂模式在面对频繁新增产品时，总会陷入修改工厂类的尴尬。本文将带你探索如何用 C++ 模板实现自动注册的工厂模式，彻底解决这一痛点。 一、传统工厂的 "if-else 地狱"假设我们要开发一个支持多种日志输出的组件（控制台日志、文件日志、网络日志），传统工厂实现可能是这样的： 123456789101112131415161718class Logger {public: virtual void log(const std::string& msg) = 0; virtual ~Logger() = default;};class ConsoleLogger : public Logger { /* 实现 */ };class FileLogger : public Logger { /* 实现 */ };class LoggerFactory {public: static std::unique_pt...

一、JWT概念JWT（JSON Web Token）是一种用于在网络上安全传输信息的紧凑、自包含的方式。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature），通过点分隔的字符串形式呈现。在身份验证和信息交换场景中应用广泛，因为它可以验证信息的完整性和真实性。 1.1 准备工作在开始之前，我们需要确保系统中安装了libjwt库，这是一个轻量级的 JWT 实现库。在 Ubuntu/Debian 系统上，可以使用以下命令安装： 1sudo apt-get install libjwt-dev 1.2 jwt.cc1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889#include <jwt.h>#include <stdio.h>#i...

要将双栈 TCP 回声服务器从线程池模式改造为Reactor 模式，核心是基于I/O 多路复用（epoll） 实现 “事件驱动” 的高效 I/O 处理 —— 通过单线程（或主线程）监听多个 Socket 的 I/O 事件，事件触发时再分发到对应处理器，避免线程上下文切换开销，更适合高并发场景。 一、Reactor 模式核心原理与组件Reactor 模式（反应器模式）是一种事件驱动架构，核心思想是 “将 I/O 事件从业务逻辑中分离”，通过以下组件实现： 组件 作用 Reactor（反应器） 核心调度器：运行事件循环，通过 I/O 多路复用（epoll）等待事件，分发事件到处理器 EventDemultiplexer 事件多路分离器：封装 epoll，负责注册 / 删除事件、等待事件触发（本文用 epoll） EventHandler（处理器） 事件处理接口：定义handleRead/handleWrite/handleError等统一接口，子类实现具体逻辑（如 “新连接处理”“回声...