Languages

一、从一个异常办不到的需求说起做过 CLI 工具或者协议解析的人都遇到过这种需求： 我走到第 3 步发现要问一下环境（"这个文件存在吗"/"用户选哪个"），拿到答案之后还要从第 3 步继续往下走。 throw 办不到。异常是单向的，throw 出去的瞬间，当前函数的栈帧就被展开销毁了，catch 手里只剩下一个异常对象，第 3 步的局部变量、循环位置、执行到哪一行——全没了。你只能从头再跑一遍，或者把状态手工拆出来存进一个上下文对象里。 这就是代数效应（algebraic effects） 想解决的问题：把"中断"和"恢复"拆开，中断的人可以把当前位置之后的整段计算（续延，continuation）打包交出去，处理的人决定怎么用它——接着跑、跑两次、或者干脆扔掉。 flowchart TB subgraph EX[异常:单向栈一展开就回不去] E1[调用 f] --> E2[f 内 throw] --> E3[栈帧逐个销毁] --> E4[cat...

你大概率没写过一行 Lua，但你的电脑每天都在跑它：Redis 的原子脚本、Nginx 的 OpenResty 插件、Wireshark 的协议解析、Neovim 的配置、魔兽世界的 UI 框架……这些八竿子打不着的软件，不约而同地选择把 Lua 嵌进去当"内脏语言"。 一门 1993 年诞生、源码只有三万多行、解释器能裁剪到 300KB 以下的小语言，凭什么被嵌入到全世界最流行的软件里？ 答案藏在一个反直觉的设计里：Lua 只有一种数据结构——table（表）。数组是它，字典是它，对象是它，模块是它，连"类"都是它。这篇文章就把它拆开讲透：这一张表，到底是怎么撑起一整门语言的。 一、从哪来：为"可嵌入"而生的小语言Lua 诞生于 1993 年，作者是巴西里约热内卢天主教大学（PUC-Rio）的 Roberto Ierusalimschy、Waldemar Celes 和 Luiz Henrique de Figueiredo。"Lua"在葡萄牙语里是"月亮"的意思——这个名字本身...

你写过这样的需求吗：查不到的配置项要有默认值；这张表不许别人改；两个"向量"要能用 + 相加、用 == 比较。 在 C++ 里，这些分别对应——给类写 getter 兜底、const 或私有成员、operator+ 与 operator== 重载。在 Python 里是 __getattr__、__setattr__、__add__、__eq__。 而在 Lua 里，它们全部是同一件事：给一张表挂上一张元表（metatable），在元表里写下双下划线开头的元方法。 Lua 没有 class 关键字，也没有运算符重载语法——所有"让一张表拥有行为"的能力，都收敛到了这一张元表里。本篇把它拆到底：查、写、运算、调用、打印、销毁，每一条路径上元表站在哪里，以及那些足以让程序静默出错的坑。 元表拦在什么位置：读路径与写路径 读：t[k] rawget(t, k) 自己身上有吗？ nil metatable.__index 表：去那张表找 非 nil：直接返回 返回值（读路径结束） 函数：调用 f(t, k) 都没有 → 返回 nil...

一、概念引入：命名冲突是怎么来的写代码写到一定规模，几乎人人都会撞上同一个尴尬： 两个第三方库都定义了一个 connect()，你 #include 进来、或者 import 进来，一调用——编译器报"重定义"、解释器静默覆盖、或者 IDE 里一片飘红。名字没变，含义变了，程序行为就跟着崩。 这就是命名冲突（name collision）：当多个名字相同、含义不同的实体被塞进同一个"符号空间"，编译器或解释器就无法区分它们。 解决思路其实很朴素——给每个名字加一个"前缀"，把一个大空间拆成若干互不干扰的小格子。这个"格子"就是命名空间（namespace）： 全局符号空间（无命名空间时） connect() 库 A 的实现 connect() 库 B 的实现 冲突! ↓ 加前缀，拆格子 ↓ netA::connect() netB::connect() 自己的 connect() 三巨头语言各自给这个"...

本文灵感来源于知乎专栏文章《最后的绅士》 一、一条刻在肌肉记忆里的铁律作为一个 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（丢失唤醒）。今天我们就来把它的原理讲透。 二、条件变量的...

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()，避免线程泄漏。 ...

一、assert 宏的基本语法与工作机制断言是 C++ 标准库提供的调试工具，核心通过头文件（兼容 C 的<assert.h>）中的assert宏实现，其本质是条件检查宏，仅在调试阶段生效。 1.1 核心语法assert宏接收一个布尔表达式作为参数，语法如下： 12345678910111213#include <cassert> // 必须包含的头文件int main() { int* ptr = new int(10); // 检查指针是否非空（调试阶段生效） assert(ptr != nullptr); delete ptr; ptr = nullptr; // 此时断言会失败（指针已置空） assert(ptr != nullptr); return 0;} 1.2 工作机制与 NDEBUG 宏assert的行为完全由 **NDEBUG宏 **（"No Debug"）控制，这是 C++ 标准规定的编译级开关： 调试模式（未定义NDEBUG）： ...

导言在 C 和 C++ 编程中，结构体（struct）是组织复杂数据的核心工具，而 typedef 则常用于简化类型名、提升代码可读性。实际开发中，我们常会见到两种结构体 + typedef 的定义方式：typedef struct Person{} Person; 与 typedef struct {} Person;。这两种写法看似相似，却因语言特性（C/C++ 差异）和结构体标签（tag）的存在与否，在使用场景、功能限制上有显著区别。 一、基础认知：结构体标签与 typedef 的作用在深入差异前，需先明确两个核心概念： 结构体标签（tag）：紧跟 struct 后的标识符（如 struct Person 中的 Person），是结构体的 “原生名称”，仅在 struct 关键字后生效。 typedef 别名：通过 typedef 为类型（包括结构体）定义的简化名称（如 Person），可直接作为类型名使用。 C 和 C++ 对 “结构体标签” 的处理规则不同，这是两种定义方式差异的根源 ——C 语言中，结构体必须通过 struct 标签 或 typede...

一、为什么“数据”需要先过一道管线，而不是裸字段真实工程里，原始输入（接口返回的 dict、配置文件、CSV 行）往往很脏：字段类型不对、越界、缺失、需要单位换算、还要派生出新的指标。如果直接把脏值塞进对象字段，后面每一处使用都得重新做判空、判范围、判类型——坑多且分散。 Python 的 property 不只是 getter/setter 的语法糖，它是在“属性访问这一刻”插入逻辑的能力。这就天然适合做一条“访问即清洗 / 校验 / 派生 / 缓存”的数据管线：调用方写 r.temp_c、r.heat_index，看起来像读普通字段，背后却已经把脏数据挡在门外。 C++ 视角对照：C++ 没有语言级 property。要实现“访问即校验 + 派生”，要么手写一堆 getX()/setX()（啰嗦，且调用方要改写法），要么依赖 Qt 的 Q_PROPERTY 宏（仅 Qt 生态、需 moc 预处理），要么用 operator>> 做流式管线（在“读取时”校验，而非“访问属性时”）。Python 用 @property 把“管线...

一、先捅破一层窗户纸：类也是对象写过几年 Python 的人大多听过一句话——"一切皆对象"。但真把这句话吃透，往往要等到第一次被元类（metaclass）绊住脚。 看一段最朴素的代码： 12345678910class User: role = "member" def greet(self): return f"hi, I am a {self.role}"u = User()print(u.greet()) # hi, I am a memberprint(type(u)) # <class '__main__.User'>print(type(User)) # <class 'type'> 输出里最后一行最反直觉：u 是 User 的实例，所以 type(u) 是 User；可 User 本身呢？type(User) 居然是 type。 本质一句话...

一、引言：当你写 obj.x = 1 时，Python 到底做了什么很多 Python 用者以为 obj.x = 1 就是"往对象里塞一个叫 x 的字段"。其实在 C 层面，它走的是 type(obj).__setattr__(obj, 'x', 1)，而 __setattr__ 在落盘之前会先去类型上找 x 是不是一个描述符——如果是，就把控制权交给描述符的协议方法。 一句话本质：描述符（descriptor）是 Python 用协议方法（__get__/__set__/__delete__）实现的"属性拦截器"，它让"读/写一个属性"变成一次可定制的函数调用；而 C++ 没有语言级的属性拦截，只能靠 getter/setter 约定或元对象编译器（如 Qt 的 moc）来近似。 坑：描述符只认类属性（定义在类型上），定义在实例字典里的同名函数不会触发协议；而且"数据描述符"和"非数据描述符"在查找优先级上完全不同，混用会出...

一、为什么单线程也能"同时"做很多 IO写爬虫或网关时，常遇到这样的场景：要同时发起上千个网络请求，每个请求大部分时间在等——等 DNS、等 TCP 握手、等对端响应。如果用"一个请求一个线程"的模型，上千线程的上下文切换和内存开销会压垮机器；如果"一个请求一个进程"，更不现实。 核心矛盾是：CPU 在等 IO 时其实是闲着的，而线程/进程的切换成本却很高。理想状态是——一个线程在等 A 的回复时，去处理 B、C 的就绪事件，等 A 回来了再回头接着 A 干。 **事件循环（event loop）**就是干这件事的调度器：它在一个线程里维护"谁在等 IO、谁已经就绪、谁该到点执行"，按需把控制权交给对应的协程。 本质一句话：事件循环是一个单线程的、基于 IO 多路复用的协作式调度器，靠"协程主动让出"而非"系统抢占"来切换任务。 C++ 对照：C++ 标准库没有内建事件循环。要么自己用 epoll/kqueue/IOCP 手写 ...

一、为什么需要"能暂停"的函数普通函数一旦被调用，就一路执行到 return 或抛异常，然后整个调用栈帧销毁，中间状态全部丢失。这在两种场景下很别扭： 处理大序列不能一次性物化。读一个几十 GB 的日志文件，如果用 readlines() 一把读进内存，内存直接爆。你真正想要的是"读一行、处理一行、扔掉一行"的流式能力。 生产/消费节奏不对等。上游产得快、下游吃得慢，或者反过来，你希望双方各自按自己的节奏走，而不是一方阻塞另一方。 生成器（generator）就是 Python 给出的答案：一个可以暂停、也可以恢复执行的函数。它在 yield 处把值交出来并"冻结"整个调用栈帧，下次再被驱动时从冻结点接着跑。 本质一句话：生成器把"函数的执行"变成了一个可以逐步消费的数据流，暂停时连调用栈一起冻结在堆上。 C++ 对照：在 C++20 之前，语言层面没有协程，要么用回调、要么自己用状态机或栈模拟"可暂停"；Python 从 PEP 255（2.2）起就有 yiel...