简介KString类是一份面向不使用MFC的C开发者的轻量字符串类实现目标是模仿CString提供构造、拷贝、拼接、查找、替换、比较、截取等常用操作同时独立于特定库便于移植到不同项目。压缩包共含3个文件KString.h声明类接口与数据成员KString.cpp给出函数实现另有一个txt资料说明文件整包仅4KB代码精简适合快速阅读与二次改造。已有229人学习下载。通过研读源码可以深入理解深拷贝与赋值运算符重载、动态内存管理与析构、流运算符重载、错误处理与容量预留等关键C机制也能借鉴如何在小型工具类中设计稳定易用的字符串操作接口。对于想提升类设计能力、或需要一套非MFC字符串方案的开发者这是一份简洁实用的参考范例。1. KString_class_src.zip 在解决什么问题需要在一个没有 MFC 的编译环境里写数据导出模块却发现自己手头的字符串处理还停留在char[]加sprintf的层次缓冲区越界、长度算错、拼接一长串临时变量调试起来非常磨人。KString_class_src.zip这一类以 CString 为范本、以 class 形式开源的字符串类就是把 MFC 里CString最常用的那套行为——动态扩容、引用计数、Format、Find、Mid——用一份独立源码复现出来让你在不依赖 MFC 的项目里也能用上同一套接口。它适合两类人一类是要把老代码移植到 Linux、嵌入式环境却又不想重写一遍字符串逻辑的工程师另一类是读过很多string教程但真正想搞懂“自己实现字符串类”时该先干什么的 C 开发者。下面按实现顺序把这套东西拆开讲。2. KString 字符串类的核心设计存储结构、引用计数与 COW 边界读 KString 这类源码前先忘掉“字符串就是char*加\0”这层印象。CString 用起来顺手根本原因是它的实例内部只保存一个指向缓冲区的指针所有自动扩容、自动算长度、号拼接的行为都是对这个指针的包装。KString 同样采用这种“瘦对象”设计对象本体只有 4 到 8 字节真正的字符数据放在堆上由统一的结构管理。先把这个布局看懂后面读接口实现就不会被指针绕晕。2.1 存储布局一个指针加一块可共享的数据块大多数 KString 风格的字符串类会在头文件里定义一个这样的私有结构// kstring.h整理后的典型布局具体字段命名因源码版本而异 class KString { public: KString(); KString(const char* psz); KString(const KString s); ~KString(); int GetLength() const; const char* GetString() const; private: struct StringData { int refCount; // 共享引用计数 int length; // 字符串逻辑长度不含结尾 \0 char data[1]; // 柔性数组标记位字符数据从这里开始 }; StringData* m_pData; // 对象真正持有的唯一指针 };StringData的char data[1]是一种兼容性写法标准 C99 叫柔性数组成员写char data[]更规范但老编译器对data[]支持不友好所以常见源码用[1]占位。对象创建时按sizeof(StringData) 字符串字节数一次性分配成员length记录逻辑长度字符数据连续跟在data之后。这样一个KString对象拷贝时只需要复制m_pData这一个指针不需要拷贝堆上的整段字符。2.1.1 从 m_pData 到字符串首地址的换算有了这个布局取字符串首地址就是一个简单的偏移计算const char* KString::GetString() const { if (m_pData nullptr) { return ; // 空对象返回空串避免解引用空指针 } return m_pData-data; // data 的地址即字符数据起点 }这里有个细节要注意data字段本身只占 1 字节但sizeof(StringData)经过对齐后通常是 8 或 12 字节所以字符数据并不紧跟结构体“零偏移”开始。好在编译器会处理对齐代码里直接return m_pData-data没有手工偏移可移植性反而比某些用(char*)(m_pData 1)的写法更稳。GetLength()则直接返回m_pData-length这也是“长度与缓冲区大小解耦”的关键设计。2.2 引用计数与写时复制性能的分水岭KString 这类类与std::string的一个明显差异在于它默认保留 CString 的引用计数 写时复制COW策略。多个对象共享同一份StringData只改refCount只有在需要修改内容时才把数据复制一份出去再改。这个设计对字符串频繁复制、少量修改的场景收益显著。操作深拷贝实现引用计数 COWKString b a;分配新内存并复制字符refCount无堆分配修改b只改 b 自己的内存先检测refCount 1再复制分离释放一个对象delete[]一次refCount--为 0 才释放写时复制最关键的一步是“修改前先分离”典型的GetBuffer逻辑如下char* KString::GetBuffer(int nMinLength) { // 需要扩容或数据被多对象共享时都要复制分离 if (m_pData nullptr || m_pData-refCount 1 || m_pData-length nMinLength) { Clone(nMinLength 0 ? nMinLength : 16); } return m_pData-data; }Clone内部会分配新StringData把原数据拷贝过去并将新对象的refCount置 1随后原对象的refCount--。调用方拿到GetBuffer返回的指针后直接写写完必须调用ReleaseBuffer重算length。漏掉这一步GetString打印出来的字符串会是脏数据这是初学者最容易踩的第一坑。2.2.1 什么时候该放弃 COWCOW 不是银弹。多线程环境下两个线程同时读同一个KStringrefCount的和--不是原子操作会出现计数错乱导致内存被提前释放。笔者的建议是如果项目里字符串会被频繁跨线程传递直接放弃 COW改用不可变共享加深度拷贝或者给refCount换成std::atomicint。判断方法很简单搜索你的 KString 源码里有没有InterlockedIncrement或__sync_add_and_fetch没有的话默认它不是线程安全的跨线程使用时必须自行加锁。3. 用 KString 类接口实现 CString 高频操作Find、Mid、Format 的可复现写法纸上谈兵结束这一章给出一套最小可运行的 KString 核心实现。不需要把所有方法都写全重点覆盖构造/析构/拷贝赋值、Find、Mid、Format这几个 CString 里使用频率最高、也最容易出问题的接口。代码在 Windows 和 Linux 下都能编译MSVC 需要#define _CRT_SECURE_NO_WARNINGS关掉vsnprintf的告警。3.1 最小骨架构造、析构、拷贝赋值一次写对// kstring.cpp最小可运行实现示意 #include kstring.h #include cstring #include cstdarg #include cstdio KString::KString() : m_pData(nullptr) {} KString::KString(const char* psz) { size_t n psz ? strlen(psz) : 0; StringData* p (StringData*)new char[sizeof(StringData) n]; p-refCount 1; p-length (int)n; if (n) { memcpy(p-data, psz, n); } p-data[n] \0; m_pData p; } KString::KString(const KString s) { if (s.m_pData) { s.m_pData-refCount; // 共享数据只加计数 m_pData s.m_pData; } else { m_pData nullptr; } } KString::~KString() { Release(); // 内部做 refCount-- 与释放 } KString KString::operator(const KString s) { if (this ! s) { // 先处理自赋值 Release(); if (s.m_pData) { s.m_pData-refCount; m_pData s.m_pData; } else { m_pData nullptr; } } return *this; } void KString::Release() { if (m_pData) { if (--m_pData-refCount 0) { delete[] (char*)m_pData; // 按原始分配方式释放 } m_pData nullptr; } }注意释放时强转回char*再delete[]因为分配时就是用new char[]分配的整块内存直接delete m_pData属于未定义行为。拷贝构造只加引用计数不复制字符这是 COW 的核心而operator里的this ! s判断是必须的否则先Release会把源头对象的数据一并释放后续s.m_pData就是悬垂指针。自赋值检查在 CString 源码中同样存在。3.2 三个高频函数Find、Mid、Format 的参数与实现int KString::Find(char ch, int iStart) const { if (m_pData nullptr || iStart 0) { return -1; } for (int i iStart; i m_pData-length; i) { if (m_pData-data[i] ch) { return i; } } return -1; // 找不到时返回 -1调用方需要显式判断 } KString KString::Mid(int iFirst, int nCount) const { if (m_pData nullptr || iFirst m_pData-length) { return KString(); } if (iFirst 0) { iFirst 0; } if (iFirst nCount m_pData-length) { nCount m_pData-length - iFirst; // 截断越界长度 } if (nCount 0) { return KString(); } KString s; char* buf s.GetBuffer(nCount); memcpy(buf, m_pData-data iFirst, nCount); buf[nCount] \0; s.ReleaseBuffer(nCount); return s; } void KString::Format(const char* pszFormat, ...) { va_list args; va_start(args, pszFormat); char stackBuf[1024]; int n vsnprintf(stackBuf, sizeof(stackBuf), pszFormat, args); va_end(args); if (n 0) { return; } if (n (int)sizeof(stackBuf)) { // 一次成功直接构造 *this KString(stackBuf); } else { // 缓冲区不足按实际长度二次分配 std::vectorchar bigBuf(n 1); va_start(args, pszFormat); vsnprintf(bigBuf.data(), bigBuf.size(), pszFormat, args); va_end(args); *this KString(bigBuf.data()); } }Find的第二个参数iStart表示起始搜索位置逻辑上和 CString 一致从iStart开始向后找找不到返回 -1。传入大于等于length的起始值属于越界直接返回 -1 而不是抛异常这是字符串类接口留给调用方的潜规则返回值必须检查。Mid的nCount超出剩余字符数时自动截断iFirst为负则归零这套防御逻辑直接照搬 CString 行为能省去调用方大量边界判断。Format是 CString 的招牌接口实现要点是先按vsnprintf尝试一次返回值小于缓冲区大小就说明成功否则按返回值动态扩容再来一次。如果直接分配一个超大的固定缓冲区高频调用时内存浪费难以接受。格式符参数和printf一致列表如下格式符含义常用示例%sC 字符串Format(%s, buf)%d/%ld有符号整数Format(%d, n)%u/%lu无符号整数Format(%08X, code)%f浮点数Format(%.2f, price)%%输出百分号Format(进度 %d%%, p)一个常被忽略的细节Format里如果要输出%必须写成%%。业务日志里常见的Format(%d%%...)误写成Format(%d%...)后vsnprintf会读取一个不存在的参数轻则格式错乱重则触发未定义行为排错时先检查这一项。4. KString 使用排错长度边界、空指针与无效的类字符串场景这一章单独拎出来因为字符串类 80% 的运行时故障集中在参数边界和对象生命周期上。KString 从 CString 继承来的接口约定并不完全直觉很多坑一旦踩中报错信息还特别隐晦。4.1 参数边界怎么设起始位置、偏移与格式符先说最容易出错的三个参数约定。GetLength()返回的是字符个数不包含结尾\0这与strlen的语义一致。GetBuffer(nMinLength)的参数是“字符容量”不是“显式长度”它只保证返回的指针能容纳nMinLength个字符调用者写完后必须用ReleaseBuffer(nLength)把真正的字符数告诉对象。// 常见错误直接写 GetBuffer(64) 后忘了 ReleaseBuffer KString log; char* p log.GetBuffer(64); strcpy(p, 001); // log.GetLength() 仍是 0GetString() 打印出来是脏数据正确做法是写完立即ReleaseBuffer(strlen(p))之后不要再保留p这个指针。Find的iStart参数同样有坑传入正数后返回值是绝对位置而不是“从 iStart 开始的偏移量”。举例来说s.Find(b, 1)在aabb里返回 2而不是 1。如果希望拿相对位置需要手工- iStart。再给出一组对比表用于快速判断返回值接口成功返回值失败返回值特别注意Find(char, int)绝对下标 0~len-1-1下标从 0 开始Mid(iFirst, nCount)新 KString 对象空字符串nCount自动截断GetLength()字符数0不含\0Compare(const char*)0 表示相同正负表示大小-与语义不同4.2 现场排错断言失败与无效的类字符串现象KString 继承自 CString 的惯用检查里最常看到的就是ASSERT(m_pData ! nullptr)这类断言失败。出现这种情况先查两件事对象是否默认构造后没经过任何初始化就被使用或者对象是否跨 DLL 边界传递导致堆句柄不一致。另一种隐蔽故障是调试器里看到m_pData的值为0xdddddddd或报出类似“无效的类字符串”的诊断。这类情况通常发生在对象指向了一块已被释放的内存某处代码delete了GetBuffer返回的指针或者把const char*存了下来后续GetString()拿到的已经是悬垂指针。处理规则只有一条GetBuffer返回的指针不允许外部持有更不允许外部释放。KString生命周期内的所有内存管理都由对象自身完成如果要用临时指针必须在ReleaseBuffer之前用完。一个值得记住的排错技巧是单步跟踪refCount。当refCount出现大于实际对象数目的值时几乎可以断定有人对同一个KString执行了两次指针赋值而没有走拷贝构造。这种问题在封装“字符串数组”时特别常见例如struct Item { KString name; }; Item a b;若误写成a.name.m_pData b.name.m_pData就是典型的引用计数失控排查方向不需要看字符内容直接看计数变化更快。5. 用类内内存计数验证 KString 的分配行为读过实现不验证等于没读。最后给一个成本最低的验证方案在 KString 内部挂一个类级计数器统计实际的新增分配和释放次数观察 COW 是否真的减少了堆分配。5.1.1 计数器挂载与统计输出在StringData结构体里加上两个静态成员对所有分配入口统一统计// kstring.h 中追加 struct StringData { static int s_alloc; // 累计分配次数 static int s_free; // 累计释放次数 // ... 其他字段 };然后在Clone和构造函数中执行s_alloc在Release实际释放内存时执行s_free。注意s_alloc统计的是真正调用new char[]的次数而不是对象构造次数——拷贝构造不触发new这正是要观察的差异点。5.1.2 压测脚本与输出对比#include cstdio // 写法示意先定义一个静态计数器为 0 int KString::StringData::s_alloc 0; int KString::StringData::s_free 0; int main() { KString a hello world; KString b a; // 拷贝构造不分配 KString c b; // 继续共享 b.GetBuffer(0); // 触发写时复制前的读写分离 b.ReleaseBuffer(); printf(alloc%d free%d\n, KString::StringData::s_alloc, KString::StringData::s_free); return 0; }运行一遍alloc是 2free是 2由静态对象析构时触发而不是 4 次字符分配。如果结果里alloc大于 2说明你的实现把拷贝构造写成了深拷贝或者构造函数里多分配了一次。再把main里第三行KString c b;改成c.GetBuffer(0)观察计数变化就能直观理解 COW 的“读共享、写复制”。把同样的用例放到多线程下跑refCount非原子导致的计数错乱就会在统计值上体现出来。整个验证流程跑通后把s_alloc与s_free抽成日志重定向到文件再跑一轮就能得到一张可对比的分配次数清单。本文还有配套的精品资源点击获取