大概每个认真学过《21天学通C》的人都会在某一章碰到那个经典的练习题自己动手写一个string类。我在一个技术社群里看到有人晒出一个叫hstring的手写string类测试题瞬间勾起了我当年被内存管理支配的日子。花了大半个晚上把思路重新捋了一遍又把实现细节全写了一遍干脆整理成这篇东西给正在啃这本书、想把基础打扎实的朋友参考。这个hstring看起来只是个阶段性成果验收但背后考的其实是C对象生命周期、深浅拷贝、运算符重载和内存管理这一连串核心硬功夫。说白了能不能把string类写好基本就是你C基础牢不牢的试金石。这篇内容适合刚学完类和对象、准备做阶段性练习的初学者也适合那些写了两年业务代码却从没自己实现过容器类、想回头补补底子的同学。我不打算只丢一份能跑通的代码而是把设计思路、为什么这么选型、踩过的坑全说出来让你写完一个class之后是真的涨了功力而不是背了个答案。1. 为什么21天教科书会安排这道题《21天学通C》系列的书国内读者很多书名里的21天被吐槽过无数次但不可否认的是它作为入门教材有一套比较完整的学习路径。等到类和对象讲完、运算符重载穿插进去作者就会安排类似实现一个简易字符串类这样的综合练习。你可能会问标准库明明有std::string手写一个出来不是重复造轮子吗1.1 这道题真正考的是对象生命周期C里最容易出问题的不是函数怎么写而是对象是怎么被创建、拷贝、赋值、销毁的。你写std::string a b;的时候编译器帮你把一切做完了代码看起来干干净净但对内存的ownership、数据的复制过程完全没有感知。一道手写字符串类的题逼着你直面最底层的三件事构造器怎么申请内存析构器怎么归还内存拷贝发生时怎么保证两个对象互不干扰这三种操作对应着C对象模型里最核心的三/五法则学不学得懂在小项目里一般体现不出来但一旦牵涉到自定义资源管理类翻不翻车全看这里趴没趴明白。hstring这个题的含金量就是把这种每个C程序员都得过一遍的核心内功以一种可以检验的形式端到你面前。1.2 两个关键维度内存管理与字节语义写string类的时候会遇到一个经典的两难拷贝到底是复制指针还是复制数据。选复制指针性能很好但两个对象指向同一块内存任谁析构都会让对方变成悬垂指针程序直接崩给你看。选复制数据安全但浪费内存和时间。这就是浅拷贝和深拷贝的分岔路。教科书在这个阶段普遍要求你实现深拷贝因为安全性优先引用计数或写时复制那套优化属于进阶玩法通常放到后续章节。我在设计hstring时遵循的也是这个逻辑先把字节语义做对——让每个字符串对象独立拥有自己的缓冲区再去想什么共享内存的骚操作。多提一句写这道题遇到的另一个让你生理性头疼的点是\0结尾符。C风格字符串靠\0标记结束但std::string本身是允许中间包含\0的。作为21天阶段的练习hstring只需要遵循C风格约定就够了但你要知道这个边界一旦有朝一日你去做通讯协议解析字符串里藏\0是家常便饭那时的设计思路就得换一套了。2. 动手前的设计思路与方案选型动手敲代码之前先把hstring的对外接口画出来。教科书里的练习题往往只要求基本功能但既然要写我建议你多考虑一步将来这段代码怎么被复用怎么读起来舒服怎么避免踩到那些坑到怀疑人生的隐蔽问题。2.1 接口层只暴露必要的部分在很多习题代码里大家习惯把所有成员都塞进public区图省事。但一个合格的hstring类必须知道什么该外露、什么该藏好构造与析构默认构造、字符串构造、拷贝构造、析构赋值操作拷贝赋值——这是大多数人第一次接触operator重载的开始容量相关返回字符串长度、判断是否为空内容访问转C风格字符串、按索引取值、修改单个字符运算符重载拼接、拼接、比较、输出内部实现字符指针、字符串长度、缓冲区分配与回收把data指针设成private是必须的这个指针就是内存的命根子一旦裸露在外面什么野指针、悬垂指针的问题都来了。用户看到这个类只需要碰几个干净的方法内部的乱七八糟跟外部环境完全绝缘这才是封装的落点。2.2 内存策略深拷贝先行但留好扩展空间我见过不少人在完成作业时顺手做了个懒拷贝——直接复制指针地址注释写着提高效率。放到考试题里这种取巧往往会被一眼看穿因为它根本绕开了考察重点。hstring我明确采用深拷贝策略理由很朴素在多数场景下字符串对象不应该意外共享同一块缓冲区。独立数据内存意味着任何对象的修改不会被其他对象无感看到这个语义和基础类型的直觉是一致的。但实现时我会把分配新内存的逻辑抽成私有方法比如reallocate或reserve这样以后想升级成写时复制或者引用计数只需要改内部实现不用动对外接口。数据结构课本教我们的道理在这里又一次应验接口和实现要分离才配叫工程实践。另外存字符串长度时我建议显式维护一个len成员而不是每次都调用strlen扫描一遍。每次get到长度都扫描一次时间复杂度从O(1)变成O(n)看起来问题不大但如果在一个循环里反复获取长度性能就成了灾难。这个小决定看着平平无奇恰恰是有没有工程意识的分水岭。2.3 教科书之外的取舍为什么不做写时复制很多读者搜资料时会看到COWCopy-On-Write写时复制这种炫酷的设计。老实讲C11之后这种手段基本被业界放弃。原因有这么几条写时复制实现线程安全极其复杂不加锁几乎不可能char*裸指针拿出去之后你根本不知道外部什么时候改了内容C11引入移动语义之后COW能省下的拷贝已经变得无关紧要手写string类的阶段别碰这个深渊。把深拷贝的每条路走稳把移动构造和移动赋值吃透性价比高得多。你以后做项目会遇到无数类似的选择题接受了教科书练习以教学为目的这个前提你就不容易在无用优化上消耗太多热情。3. 核心代码实现与关键细节解析这段直接上实现思路。我尽量把每个关键步骤都拆开来解释包括参数是怎么算出来的为什么这样写以及哪些地方最容易踩坑。3.1 类的骨架设计#include iostream #include cstring class hstring { public: // 构造与析构 hstring(); hstring(const char* str); hstring(const hstring other); ~hstring(); // 赋值操作 hstring operator(const hstring other); // 容量相关 size_t size() const; size_t length() const; bool empty() const; // 元素访问 const char* c_str() const; char operator[](size_t index); const char operator[](size_t index) const; // 拼接与比较 hstring operator(const hstring other); friend hstring operator(const hstring lhs, const hstring rhs); bool operator(const hstring other) const; bool operator!(const hstring other) const; // 输出 friend std::ostream operator(std::ostream os, const hstring str); private: char* data; size_t len; void init_from_cstr(const char* str); void destroy(); };在这份代码里我把data和len放在了private只留该给的接口给用户碰。friend只给了外部的operator和operator因为这两个函数确实需要访问内部数据。这不是懒是C设计原则中最小权限的体现——能不改动类内部声明就不改动尽量缩小暴露面积。3.2 构造内存从哪里来到哪里去默认构造和字符串构造hstring::hstring() : data(nullptr), len(0) { data new char[1]; data[0] \0; } hstring::hstring(const char* str) : data(nullptr), len(0) { if (str nullptr) { data new char[1]; data[0] \0; return; } len strlen(str); data new char[len 1]; strcpy(data, str); }注意默认构造中我仍然给data分配了一块能容纳\0的内存。为什么要这样因为c_str()返回的指针必须永远合法任何接口实现都不该让用户拿到悬垂指针。有些习题答案把data初始化为nullptr等到c_str()调用时才判空也算一种做法但空字符串对象仍然拥有可访问的内存是更安全的方案。len strlen(str);这里先拿到长度再按len 1分配——加的那个1专门放字符串结尾符。如果漏掉这个1把\0写到缓冲区外面去程序在运行期会踩到随机内存轻则输出乱码重则直接段错误。这一点被无数人忽略是内存类练习里最常见也最经典的错误。关于new char[len 1]为什么不直接new char[strlen(str) 1]主要是代码可读性和异常安全性的考虑。把strlen结果先存到len后续size()这些方法就能直接复用不用再次扫描字符串。3.3 拷贝构造与拷贝赋值深拷贝决战场hstring::hstring(const hstring other) : data(nullptr), len(other.len) { data new char[len 1]; strcpy(data, other.data); } hstring hstring::operator(const hstring other) { if (this other) { return *this; } delete[] data; len other.len; data new char[len 1]; strcpy(data, other.data); return *this; }赋值操作符这块儿有一道很难觉察的坎自我赋值。str str;这种代码如果出现在你的项目里并且你没做自我判断会先delete[]掉自己的数据然后拿着一个被释放掉的地址去拷贝直接把程序送走。你可能会说我怎么可能写str str这种代码——确实不会直接写但是当赋值和别名搅在一起时就危险了。比如存在一个hstring ref str;某个分支里执行str ref;你在写代码时根本看不出这是自我赋值。所以教科书总是强调写赋值操作符第一行先判断是不是自己。我还采用了先释放后重新分配的策略这个策略在多数情况下是主流做法因为它逻辑清晰、容易验证。但它在异常安全上存在隐患如果new char[]抛异常对象已经被摧毁了。这个问题很进阶通常引入copy-and-swap惯用法来解决。在这阶段我建议你用最直接的先后顺序方案但要清楚它的局限。3.4 拼接操作与运算符重载的取舍拼接这块最容易出现的毛病是用完之后忘记返回引用。我把两个运算的差异摆出来hstring hstring::operator(const hstring other) { size_t new_len len other.len; char* new_data new char[new_len 1]; strcpy(new_data, data); strcat(new_data, other.data); delete[] data; data new_data; len new_len; return *this; } hstring operator(const hstring lhs, const hstring rhs) { hstring result lhs; result rhs; return result; }是在自己身上做增量修改返回hstring是链式调用a b c;的钥匙不返回引用编译器会报错或者生成临时对象事倍功半。则不同它是非成员函数因为两侧参数都可能发生隐式类型转换如果定义成成员函数hello str这种形式会编译失败。让operator调用operator来复用逻辑是我在实际开发中总结出的最不易出错的设计——你只把真正的数据搬运写一遍其他接口全基于它扩展代码的维护成本直线下降。friend hstring operator(...)是必须的吗严格说如果只访问了public接口可以不设friend。但operator访问并不需要friend真正的friend需求来自operator以及未来可能的内部结构操作。在hstring这个练习中cin和cout是标配所以我把operator设计为friend直接访问data和len来逐个输出。比较运算符我建议用strcmp但前提是内部字符串约定以\0结尾——这正是我们前面坚持末尾必有结束符的回报。3.5 大小接口与索引边界size_t hstring::size() const { return len; } bool hstring::empty() const { return len 0; } char hstring::operator[](size_t index) { return data[index]; } const char hstring::operator[](size_t index) const { return data[index]; }关于operator[]要不要检查越界业界分歧很大。标准库的std::string在operator[]中不保证越界检查那是at()的职责目的就是极致性能。hstring作为教学练习我同样选择不检查但你要清楚地知道这是个性能和安全的权衡设计。如果用户拿越界下标去访问会直接从data[index]跑到缓冲区外读出来的是垃圾写进去就是内存破坏。如果这是用来上课交作业的代码建议你在注释里写明未定义行为四个大字至少让阅卷老师看见你明白这个语义。如果想加检查就额外写个at(size_t)方法内部用if (index len) throw std::out_of_range(...)把异常抛出来。这种方式既照顾了安全性也保留了[]操作符的高速通道。4. 实际测试与常见问题排查实录代码写完了不是终点真正的挑战从你开始跑测试的那一刻才降临。我把自己实测踩过的坑和一些经典问题整理成速查表帮你省掉大量查资料的功夫。4.1 三种一跑就崩的经典错误第一类错误是空指针解引用。很多同学在默认构造里偷懒不初始化data或者初始化为nullptr后面一旦调用strcpy(data, other.data)试图往空指针地址拷贝数据程序当场崩溃。对这个问题的排查思路很直接把类里所有用到data的地方全部列出来检查每一个分支执行时data是否一定非空。最好的解决方案就是我前文写的默认构造分配一块new char[1]从源头杜绝悬垂。第二类错误是内存泄漏。new了之后忘了delete[]运行一万次就能把内存耗尽。排查方法是用工具Linux下的valgrind是神器Windows的Visual Studio也有_CrtDumpMemoryLeaks()。测试完代码跑一次内存检测比自己瞪大眼睛盯代码强得多。第三类错误是自赋值崩溃刚才提过表现特征很奇怪不是每次都会崩而是偶尔崩。因为字符串内容相同时delete[]之后的数据在内存里还是原样的概率很高strcpy居然能自欺欺人地复制成功。哪天缓冲区被回收重用了才露出狰狞面目。这就是为什么开头的if (this other)判断绝对不能省。错误类型现象根治方案空指针解引用构造后立刻崩溃默认构造也分配内存保证data非空内存泄漏长时间运行内存暴涨new/delete成对检查配合valgrind自赋值崩溃偶尔崩溃、随机崩溃operator开头判断this地址深拷贝缺失两个对象互相影响拷贝时new新内存逐字节拷贝缓冲区溢出字符串末尾乱码new时长度必须len 14.2 功能测试哪一种测试值得我们写写hstring的主要目的是学习不是交付商业代码所以不用重型测试框架写几段性感的自测就够了。我的习惯是用一个main函数把所有功能一次性检验一遍int main() { hstring s1; std::cout s1为空: s1.empty() , 输出: [ s1 ] std::endl; hstring s2(hello); hstring s3(s2); std::cout s2: s2 , s3拷贝构造: s3 std::endl; hstring s4; s4 s2; std::cout s4赋值: s4 std::endl; s4 world; std::cout s4拼接后: s4 std::endl; hstring s5 s2 cpp; std::cout s5用operator: s5 std::endl; if (s2 s3) { std::cout s2与s3相等 std::endl; } s2[0] H; std::cout s2修改后: s2 , s3不变: s3 std::endl; return 0; }这段测试有个容易被忽略的价值它验证了深拷贝最重要的场景——修改s2的某个字符s3的内容不应该跟着变。如果你偷懒用了浅拷贝或者operator只是指针赋值那么s2[0] H这行之后s3打印出来也会变成Hello测试会立刻暴露问题。测试时我发现一个关于size()返回类型的细节应该用size_t而不是int。从纯数学上看字符串长度是非负数int有符号特性是多余的从兼容性看标准库字符串的长度类型就是size_t如果你的类将来要和标准库容器互操作类型对不上就要做一堆强制转换非常别扭。4.3 与标准库string的差异你心里要有数写完hstring你可能会不由自主拿它和std::string对比然后陷入自我怀疑。别这样hstring的目标从来不是再造一个标准库而是帮你理解底层。因此两者之间的差异正是学习价值所在std::string支持移动语义hstring在这个阶段未必支持std::string支持find、substr等大量算法hstring只实现了基础接口std::string在不同编译器和标准库中可能有小字符串优化hstring用的是裸堆内存std::string的c_str()在原字符串被修改后可能失效hstring同样如此——这个隐藏坑连有经验的人也会在长生命周期项目中偶遇这些差异说明了两件事标准库实现者在工程上做了大量取舍来兼顾性能、安全与易用性而这些取舍恰恰是你可以通过手写string去逐步领悟的。先完成hstring的功能再去看std::string源码或者网上那些分析std::string实现的文章你会获得豁然开朗的体验。5. 从手写string到真实工程的进阶路线hstring写完了、测试通过了、21天阶段性目标达成了然后呢把这段代码丢进回收站就太浪费了。从手写string到真实工程能力之间还有几级台阶你可以趁热打铁爬上去。5.1 第一个进阶无异常版本的思考我在3.3节提到先释放后分配在异常安全上的隐患。想让hstring真正达到工业级就要引入copy-and-swap惯用法void swap(hstring other) noexcept { std::swap(data, other.data); std::swap(len, other.len); } hstring operator(const hstring other) { hstring temp(other); swap(temp); return *this; }原理很好理解先用other拷贝构造一个临时变量如果拷贝过程中内存分配失败抛出异常此时的*this完好无损。如果拷贝成功交换临时变量和当前对象的内容临时变量析构时把旧内存释放。这个方法把赋值变成构造交换析构的组合操作从结构上消灭了异常安全问题。我非常建议你把这段代码亲手写进hstring再用异常注入的方式模拟new失败场景感受一下跟旧版本的区别。这个习惯对你以后写任何资源管理类都有不可估量的帮助。5.2 第二个进阶移动构造与移动语义C11之后移动语义是新标准的重要内容。给hstring加上移动构造和移动赋值代码不复杂hstring(hstring other) noexcept : data(other.data), len(other.len) { other.data nullptr; other.len 0; } hstring operator(hstring other) noexcept { if (this other) { return *this; } delete[] data; data other.data; len other.len; other.data nullptr; other.len 0; return *this; }移动构造的本质是偷走别人的资源。other.data nullptr这行尤其重要置空之后临时对象的析构函数释放一块空指针是安全的不会释放掉刚被偷走的数据。注意析构对nullptr做delete[]是合法的这算C的一条语言福利但要记得在析构里判空或者其他方式保证安全。有了移动构造和移动赋值三法则这个要求就升级成五法则——五法则的含义是如果需要自定义析构函数、拷贝构造或拷贝赋值三者中的任何一个通常意味着这三个都需要你自己写而一旦涉及移动操作移动构造和移动赋值也要一起考虑。这也是为什么很多面试官喜欢拿string类做考点它完美覆盖了五法则的所有内容。5.3 第三个进阶在真实项目里用hstring积累经验自己手写的hstring可以怎么用而不显得无聊你可以把它作为缓存容器来存储命令行的历史记录或者把它嵌到一个简单的文本统计小工具里。我自己做的实验是写了一个小型的词频统计功能用hstring存储每个单词然后把它们塞进一个std::vectorhstring里观察拷贝带来的性能开销。这个实验的收获很大。你会在亲身体会中懂得为什么标准库提供那么多优化——当你统计一本几百页的英文书几千个单词在vector里反复扩容、拷贝、再扩容时肉眼可见的性能损耗会让你重新审视深浅拷贝这个看似基础的概念。你也马上会想了解reserve和shrink_to_fit的机制这又触发了对vector内存模型的进一步学习。在这个过程里别忘了用工具检测问题。valgrind、AddressSanitizer、_CrtDbg都行关键是养成习惯。写过一次带内存问题的类并亲眼看到检测工具定位到那一行代码之后你就再也回不到只管实现不管内存的舒适区了。6. 给练习题答卷人的实操建议如果这篇博客触发的场景是你正准备交一份hstring的阶段性测试题那么下面这些建议是我结合自己看作业和写代码的双重经验总结出来的照着做效果至少能上一个台阶。6.1 写代码时保持注释与实现同步习题代码不要写注释或者写太多花哨注释而是要在关键处用注释说明设计动机。比如在operator开头的自赋值判断旁写一行// 防止自我赋值导致野指针的问题阅卷老师一瞬间就能捕捉到你的工程素养。反过来在new char[len 1]旁边写一句// 末尾的1给\0留位置就证明你踩过或者认真看过这个经典坑。6.2 必要的方法也考虑const正确性很多初学者写方法时漏掉const修饰比如size_t size() { return len; }这会导致一个尴尬的场景一个const的hstring对象无法调用size()方法。比较运算符operator如果你写的不够const那两边有const引用时照样编译不过。且不说工程实践单单老师布置的测试代码里如果有一个const hstring a(hello); a.size();的调用你就要吃编译错误。你只需要记住一条标准不修改任何类成员的方法都加const。这个习惯一旦养成你的代码跟别人之间的差距会肉眼可见地拉开。6.3 亲手把代码再抄一遍网上关于hstring或者手写string类的代码一搜一大把但单纯复制粘贴不会有任何长进。我强烈建议你照着思路自己敲一遍再故意制造几个bug去验证你的理解。比如你可以改动一行把深拷贝改成浅拷贝跑一遍之前的测试聊聊会发生什么或者删掉默认构造中的data new char[1]看看哪些操作会崩。这种故意搞坏代码再修复的方式被很多人戏称为负向教学法我实测下来是巩固C底层概念最有效的方法之一。7. 总结与个人实践体会写到这里hstring这道题的核心内容其实已经全讲完了。六年前我第一次接触这个练习题时写了整整一个晚上期间无数次刷新编译错误、谷歌解决方案最终在第二天凌晨把代码调通。现在回头看那一个晚上的收获比之后连续刷两个星期的教程都大。如果你让我说说对《21天学通C》阶段性成果测试题——hstring手写string类这个标题的整体评价我会说这是一个被严重低估的教学设计。它不像很多练习题那样只考某个孤立语法而是用一种你必须亲自从零构建一个基础工具的方式把C中最容易蒙混过关的对象生命周期、资源管理、运算符重载等核心知识全部串联起来。交作业或者自我练习时别满足于跑通再多走一步加上移动语义、验证const正确性、跑一遍内存检测、想想copy-and-swap比先释放后分配好在哪。当你把这些都做完了你会发现你不在是那个只会调用std::string的初学者而是开始用package designer的视角审视C这门语言。这才是hstring真正想教会你的东西。
大概每个认真学过《21天学通C》的人都会在某一章碰到那个经典的练习题自己动手写一个string类。我在一个技术社群里看到有人晒出一个叫hstring的手写string类测试题瞬间勾起了我当年被内存管理支配的日子。花了大半个晚上把思路重新捋了一遍又把实现细节全写了一遍干脆整理成这篇东西给正在啃这本书、想把基础打扎实的朋友参考。这个hstring看起来只是个阶段性成果验收但背后考的其实是C对象生命周期、深浅拷贝、运算符重载和内存管理这一连串核心硬功夫。说白了能不能把string类写好基本就是你C基础牢不牢的试金石。这篇内容适合刚学完类和对象、准备做阶段性练习的初学者也适合那些写了两年业务代码却从没自己实现过容器类、想回头补补底子的同学。我不打算只丢一份能跑通的代码而是把设计思路、为什么这么选型、踩过的坑全说出来让你写完一个class之后是真的涨了功力而不是背了个答案。1. 为什么21天教科书会安排这道题《21天学通C》系列的书国内读者很多书名里的21天被吐槽过无数次但不可否认的是它作为入门教材有一套比较完整的学习路径。等到类和对象讲完、运算符重载穿插进去作者就会安排类似实现一个简易字符串类这样的综合练习。你可能会问标准库明明有std::string手写一个出来不是重复造轮子吗1.1 这道题真正考的是对象生命周期C里最容易出问题的不是函数怎么写而是对象是怎么被创建、拷贝、赋值、销毁的。你写std::string a b;的时候编译器帮你把一切做完了代码看起来干干净净但对内存的ownership、数据的复制过程完全没有感知。一道手写字符串类的题逼着你直面最底层的三件事构造器怎么申请内存析构器怎么归还内存拷贝发生时怎么保证两个对象互不干扰这三种操作对应着C对象模型里最核心的三/五法则学不学得懂在小项目里一般体现不出来但一旦牵涉到自定义资源管理类翻不翻车全看这里趴没趴明白。hstring这个题的含金量就是把这种每个C程序员都得过一遍的核心内功以一种可以检验的形式端到你面前。1.2 两个关键维度内存管理与字节语义写string类的时候会遇到一个经典的两难拷贝到底是复制指针还是复制数据。选复制指针性能很好但两个对象指向同一块内存任谁析构都会让对方变成悬垂指针程序直接崩给你看。选复制数据安全但浪费内存和时间。这就是浅拷贝和深拷贝的分岔路。教科书在这个阶段普遍要求你实现深拷贝因为安全性优先引用计数或写时复制那套优化属于进阶玩法通常放到后续章节。我在设计hstring时遵循的也是这个逻辑先把字节语义做对——让每个字符串对象独立拥有自己的缓冲区再去想什么共享内存的骚操作。多提一句写这道题遇到的另一个让你生理性头疼的点是\0结尾符。C风格字符串靠\0标记结束但std::string本身是允许中间包含\0的。作为21天阶段的练习hstring只需要遵循C风格约定就够了但你要知道这个边界一旦有朝一日你去做通讯协议解析字符串里藏\0是家常便饭那时的设计思路就得换一套了。2. 动手前的设计思路与方案选型动手敲代码之前先把hstring的对外接口画出来。教科书里的练习题往往只要求基本功能但既然要写我建议你多考虑一步将来这段代码怎么被复用怎么读起来舒服怎么避免踩到那些坑到怀疑人生的隐蔽问题。2.1 接口层只暴露必要的部分在很多习题代码里大家习惯把所有成员都塞进public区图省事。但一个合格的hstring类必须知道什么该外露、什么该藏好构造与析构默认构造、字符串构造、拷贝构造、析构赋值操作拷贝赋值——这是大多数人第一次接触operator重载的开始容量相关返回字符串长度、判断是否为空内容访问转C风格字符串、按索引取值、修改单个字符运算符重载拼接、拼接、比较、输出内部实现字符指针、字符串长度、缓冲区分配与回收把data指针设成private是必须的这个指针就是内存的命根子一旦裸露在外面什么野指针、悬垂指针的问题都来了。用户看到这个类只需要碰几个干净的方法内部的乱七八糟跟外部环境完全绝缘这才是封装的落点。2.2 内存策略深拷贝先行但留好扩展空间我见过不少人在完成作业时顺手做了个懒拷贝——直接复制指针地址注释写着提高效率。放到考试题里这种取巧往往会被一眼看穿因为它根本绕开了考察重点。hstring我明确采用深拷贝策略理由很朴素在多数场景下字符串对象不应该意外共享同一块缓冲区。独立数据内存意味着任何对象的修改不会被其他对象无感看到这个语义和基础类型的直觉是一致的。但实现时我会把分配新内存的逻辑抽成私有方法比如reallocate或reserve这样以后想升级成写时复制或者引用计数只需要改内部实现不用动对外接口。数据结构课本教我们的道理在这里又一次应验接口和实现要分离才配叫工程实践。另外存字符串长度时我建议显式维护一个len成员而不是每次都调用strlen扫描一遍。每次get到长度都扫描一次时间复杂度从O(1)变成O(n)看起来问题不大但如果在一个循环里反复获取长度性能就成了灾难。这个小决定看着平平无奇恰恰是有没有工程意识的分水岭。2.3 教科书之外的取舍为什么不做写时复制很多读者搜资料时会看到COWCopy-On-Write写时复制这种炫酷的设计。老实讲C11之后这种手段基本被业界放弃。原因有这么几条写时复制实现线程安全极其复杂不加锁几乎不可能char*裸指针拿出去之后你根本不知道外部什么时候改了内容C11引入移动语义之后COW能省下的拷贝已经变得无关紧要手写string类的阶段别碰这个深渊。把深拷贝的每条路走稳把移动构造和移动赋值吃透性价比高得多。你以后做项目会遇到无数类似的选择题接受了教科书练习以教学为目的这个前提你就不容易在无用优化上消耗太多热情。3. 核心代码实现与关键细节解析这段直接上实现思路。我尽量把每个关键步骤都拆开来解释包括参数是怎么算出来的为什么这样写以及哪些地方最容易踩坑。3.1 类的骨架设计#include iostream #include cstring class hstring { public: // 构造与析构 hstring(); hstring(const char* str); hstring(const hstring other); ~hstring(); // 赋值操作 hstring operator(const hstring other); // 容量相关 size_t size() const; size_t length() const; bool empty() const; // 元素访问 const char* c_str() const; char operator[](size_t index); const char operator[](size_t index) const; // 拼接与比较 hstring operator(const hstring other); friend hstring operator(const hstring lhs, const hstring rhs); bool operator(const hstring other) const; bool operator!(const hstring other) const; // 输出 friend std::ostream operator(std::ostream os, const hstring str); private: char* data; size_t len; void init_from_cstr(const char* str); void destroy(); };在这份代码里我把data和len放在了private只留该给的接口给用户碰。friend只给了外部的operator和operator因为这两个函数确实需要访问内部数据。这不是懒是C设计原则中最小权限的体现——能不改动类内部声明就不改动尽量缩小暴露面积。3.2 构造内存从哪里来到哪里去默认构造和字符串构造hstring::hstring() : data(nullptr), len(0) { data new char[1]; data[0] \0; } hstring::hstring(const char* str) : data(nullptr), len(0) { if (str nullptr) { data new char[1]; data[0] \0; return; } len strlen(str); data new char[len 1]; strcpy(data, str); }注意默认构造中我仍然给data分配了一块能容纳\0的内存。为什么要这样因为c_str()返回的指针必须永远合法任何接口实现都不该让用户拿到悬垂指针。有些习题答案把data初始化为nullptr等到c_str()调用时才判空也算一种做法但空字符串对象仍然拥有可访问的内存是更安全的方案。len strlen(str);这里先拿到长度再按len 1分配——加的那个1专门放字符串结尾符。如果漏掉这个1把\0写到缓冲区外面去程序在运行期会踩到随机内存轻则输出乱码重则直接段错误。这一点被无数人忽略是内存类练习里最常见也最经典的错误。关于new char[len 1]为什么不直接new char[strlen(str) 1]主要是代码可读性和异常安全性的考虑。把strlen结果先存到len后续size()这些方法就能直接复用不用再次扫描字符串。3.3 拷贝构造与拷贝赋值深拷贝决战场hstring::hstring(const hstring other) : data(nullptr), len(other.len) { data new char[len 1]; strcpy(data, other.data); } hstring hstring::operator(const hstring other) { if (this other) { return *this; } delete[] data; len other.len; data new char[len 1]; strcpy(data, other.data); return *this; }赋值操作符这块儿有一道很难觉察的坎自我赋值。str str;这种代码如果出现在你的项目里并且你没做自我判断会先delete[]掉自己的数据然后拿着一个被释放掉的地址去拷贝直接把程序送走。你可能会说我怎么可能写str str这种代码——确实不会直接写但是当赋值和别名搅在一起时就危险了。比如存在一个hstring ref str;某个分支里执行str ref;你在写代码时根本看不出这是自我赋值。所以教科书总是强调写赋值操作符第一行先判断是不是自己。我还采用了先释放后重新分配的策略这个策略在多数情况下是主流做法因为它逻辑清晰、容易验证。但它在异常安全上存在隐患如果new char[]抛异常对象已经被摧毁了。这个问题很进阶通常引入copy-and-swap惯用法来解决。在这阶段我建议你用最直接的先后顺序方案但要清楚它的局限。3.4 拼接操作与运算符重载的取舍拼接这块最容易出现的毛病是用完之后忘记返回引用。我把两个运算的差异摆出来hstring hstring::operator(const hstring other) { size_t new_len len other.len; char* new_data new char[new_len 1]; strcpy(new_data, data); strcat(new_data, other.data); delete[] data; data new_data; len new_len; return *this; } hstring operator(const hstring lhs, const hstring rhs) { hstring result lhs; result rhs; return result; }是在自己身上做增量修改返回hstring是链式调用a b c;的钥匙不返回引用编译器会报错或者生成临时对象事倍功半。则不同它是非成员函数因为两侧参数都可能发生隐式类型转换如果定义成成员函数hello str这种形式会编译失败。让operator调用operator来复用逻辑是我在实际开发中总结出的最不易出错的设计——你只把真正的数据搬运写一遍其他接口全基于它扩展代码的维护成本直线下降。friend hstring operator(...)是必须的吗严格说如果只访问了public接口可以不设friend。但operator访问并不需要friend真正的friend需求来自operator以及未来可能的内部结构操作。在hstring这个练习中cin和cout是标配所以我把operator设计为friend直接访问data和len来逐个输出。比较运算符我建议用strcmp但前提是内部字符串约定以\0结尾——这正是我们前面坚持末尾必有结束符的回报。3.5 大小接口与索引边界size_t hstring::size() const { return len; } bool hstring::empty() const { return len 0; } char hstring::operator[](size_t index) { return data[index]; } const char hstring::operator[](size_t index) const { return data[index]; }关于operator[]要不要检查越界业界分歧很大。标准库的std::string在operator[]中不保证越界检查那是at()的职责目的就是极致性能。hstring作为教学练习我同样选择不检查但你要清楚地知道这是个性能和安全的权衡设计。如果用户拿越界下标去访问会直接从data[index]跑到缓冲区外读出来的是垃圾写进去就是内存破坏。如果这是用来上课交作业的代码建议你在注释里写明未定义行为四个大字至少让阅卷老师看见你明白这个语义。如果想加检查就额外写个at(size_t)方法内部用if (index len) throw std::out_of_range(...)把异常抛出来。这种方式既照顾了安全性也保留了[]操作符的高速通道。4. 实际测试与常见问题排查实录代码写完了不是终点真正的挑战从你开始跑测试的那一刻才降临。我把自己实测踩过的坑和一些经典问题整理成速查表帮你省掉大量查资料的功夫。4.1 三种一跑就崩的经典错误第一类错误是空指针解引用。很多同学在默认构造里偷懒不初始化data或者初始化为nullptr后面一旦调用strcpy(data, other.data)试图往空指针地址拷贝数据程序当场崩溃。对这个问题的排查思路很直接把类里所有用到data的地方全部列出来检查每一个分支执行时data是否一定非空。最好的解决方案就是我前文写的默认构造分配一块new char[1]从源头杜绝悬垂。第二类错误是内存泄漏。new了之后忘了delete[]运行一万次就能把内存耗尽。排查方法是用工具Linux下的valgrind是神器Windows的Visual Studio也有_CrtDumpMemoryLeaks()。测试完代码跑一次内存检测比自己瞪大眼睛盯代码强得多。第三类错误是自赋值崩溃刚才提过表现特征很奇怪不是每次都会崩而是偶尔崩。因为字符串内容相同时delete[]之后的数据在内存里还是原样的概率很高strcpy居然能自欺欺人地复制成功。哪天缓冲区被回收重用了才露出狰狞面目。这就是为什么开头的if (this other)判断绝对不能省。错误类型现象根治方案空指针解引用构造后立刻崩溃默认构造也分配内存保证data非空内存泄漏长时间运行内存暴涨new/delete成对检查配合valgrind自赋值崩溃偶尔崩溃、随机崩溃operator开头判断this地址深拷贝缺失两个对象互相影响拷贝时new新内存逐字节拷贝缓冲区溢出字符串末尾乱码new时长度必须len 14.2 功能测试哪一种测试值得我们写写hstring的主要目的是学习不是交付商业代码所以不用重型测试框架写几段性感的自测就够了。我的习惯是用一个main函数把所有功能一次性检验一遍int main() { hstring s1; std::cout s1为空: s1.empty() , 输出: [ s1 ] std::endl; hstring s2(hello); hstring s3(s2); std::cout s2: s2 , s3拷贝构造: s3 std::endl; hstring s4; s4 s2; std::cout s4赋值: s4 std::endl; s4 world; std::cout s4拼接后: s4 std::endl; hstring s5 s2 cpp; std::cout s5用operator: s5 std::endl; if (s2 s3) { std::cout s2与s3相等 std::endl; } s2[0] H; std::cout s2修改后: s2 , s3不变: s3 std::endl; return 0; }这段测试有个容易被忽略的价值它验证了深拷贝最重要的场景——修改s2的某个字符s3的内容不应该跟着变。如果你偷懒用了浅拷贝或者operator只是指针赋值那么s2[0] H这行之后s3打印出来也会变成Hello测试会立刻暴露问题。测试时我发现一个关于size()返回类型的细节应该用size_t而不是int。从纯数学上看字符串长度是非负数int有符号特性是多余的从兼容性看标准库字符串的长度类型就是size_t如果你的类将来要和标准库容器互操作类型对不上就要做一堆强制转换非常别扭。4.3 与标准库string的差异你心里要有数写完hstring你可能会不由自主拿它和std::string对比然后陷入自我怀疑。别这样hstring的目标从来不是再造一个标准库而是帮你理解底层。因此两者之间的差异正是学习价值所在std::string支持移动语义hstring在这个阶段未必支持std::string支持find、substr等大量算法hstring只实现了基础接口std::string在不同编译器和标准库中可能有小字符串优化hstring用的是裸堆内存std::string的c_str()在原字符串被修改后可能失效hstring同样如此——这个隐藏坑连有经验的人也会在长生命周期项目中偶遇这些差异说明了两件事标准库实现者在工程上做了大量取舍来兼顾性能、安全与易用性而这些取舍恰恰是你可以通过手写string去逐步领悟的。先完成hstring的功能再去看std::string源码或者网上那些分析std::string实现的文章你会获得豁然开朗的体验。5. 从手写string到真实工程的进阶路线hstring写完了、测试通过了、21天阶段性目标达成了然后呢把这段代码丢进回收站就太浪费了。从手写string到真实工程能力之间还有几级台阶你可以趁热打铁爬上去。5.1 第一个进阶无异常版本的思考我在3.3节提到先释放后分配在异常安全上的隐患。想让hstring真正达到工业级就要引入copy-and-swap惯用法void swap(hstring other) noexcept { std::swap(data, other.data); std::swap(len, other.len); } hstring operator(const hstring other) { hstring temp(other); swap(temp); return *this; }原理很好理解先用other拷贝构造一个临时变量如果拷贝过程中内存分配失败抛出异常此时的*this完好无损。如果拷贝成功交换临时变量和当前对象的内容临时变量析构时把旧内存释放。这个方法把赋值变成构造交换析构的组合操作从结构上消灭了异常安全问题。我非常建议你把这段代码亲手写进hstring再用异常注入的方式模拟new失败场景感受一下跟旧版本的区别。这个习惯对你以后写任何资源管理类都有不可估量的帮助。5.2 第二个进阶移动构造与移动语义C11之后移动语义是新标准的重要内容。给hstring加上移动构造和移动赋值代码不复杂hstring(hstring other) noexcept : data(other.data), len(other.len) { other.data nullptr; other.len 0; } hstring operator(hstring other) noexcept { if (this other) { return *this; } delete[] data; data other.data; len other.len; other.data nullptr; other.len 0; return *this; }移动构造的本质是偷走别人的资源。other.data nullptr这行尤其重要置空之后临时对象的析构函数释放一块空指针是安全的不会释放掉刚被偷走的数据。注意析构对nullptr做delete[]是合法的这算C的一条语言福利但要记得在析构里判空或者其他方式保证安全。有了移动构造和移动赋值三法则这个要求就升级成五法则——五法则的含义是如果需要自定义析构函数、拷贝构造或拷贝赋值三者中的任何一个通常意味着这三个都需要你自己写而一旦涉及移动操作移动构造和移动赋值也要一起考虑。这也是为什么很多面试官喜欢拿string类做考点它完美覆盖了五法则的所有内容。5.3 第三个进阶在真实项目里用hstring积累经验自己手写的hstring可以怎么用而不显得无聊你可以把它作为缓存容器来存储命令行的历史记录或者把它嵌到一个简单的文本统计小工具里。我自己做的实验是写了一个小型的词频统计功能用hstring存储每个单词然后把它们塞进一个std::vectorhstring里观察拷贝带来的性能开销。这个实验的收获很大。你会在亲身体会中懂得为什么标准库提供那么多优化——当你统计一本几百页的英文书几千个单词在vector里反复扩容、拷贝、再扩容时肉眼可见的性能损耗会让你重新审视深浅拷贝这个看似基础的概念。你也马上会想了解reserve和shrink_to_fit的机制这又触发了对vector内存模型的进一步学习。在这个过程里别忘了用工具检测问题。valgrind、AddressSanitizer、_CrtDbg都行关键是养成习惯。写过一次带内存问题的类并亲眼看到检测工具定位到那一行代码之后你就再也回不到只管实现不管内存的舒适区了。6. 给练习题答卷人的实操建议如果这篇博客触发的场景是你正准备交一份hstring的阶段性测试题那么下面这些建议是我结合自己看作业和写代码的双重经验总结出来的照着做效果至少能上一个台阶。6.1 写代码时保持注释与实现同步习题代码不要写注释或者写太多花哨注释而是要在关键处用注释说明设计动机。比如在operator开头的自赋值判断旁写一行// 防止自我赋值导致野指针的问题阅卷老师一瞬间就能捕捉到你的工程素养。反过来在new char[len 1]旁边写一句// 末尾的1给\0留位置就证明你踩过或者认真看过这个经典坑。6.2 必要的方法也考虑const正确性很多初学者写方法时漏掉const修饰比如size_t size() { return len; }这会导致一个尴尬的场景一个const的hstring对象无法调用size()方法。比较运算符operator如果你写的不够const那两边有const引用时照样编译不过。且不说工程实践单单老师布置的测试代码里如果有一个const hstring a(hello); a.size();的调用你就要吃编译错误。你只需要记住一条标准不修改任何类成员的方法都加const。这个习惯一旦养成你的代码跟别人之间的差距会肉眼可见地拉开。6.3 亲手把代码再抄一遍网上关于hstring或者手写string类的代码一搜一大把但单纯复制粘贴不会有任何长进。我强烈建议你照着思路自己敲一遍再故意制造几个bug去验证你的理解。比如你可以改动一行把深拷贝改成浅拷贝跑一遍之前的测试聊聊会发生什么或者删掉默认构造中的data new char[1]看看哪些操作会崩。这种故意搞坏代码再修复的方式被很多人戏称为负向教学法我实测下来是巩固C底层概念最有效的方法之一。7. 总结与个人实践体会写到这里hstring这道题的核心内容其实已经全讲完了。六年前我第一次接触这个练习题时写了整整一个晚上期间无数次刷新编译错误、谷歌解决方案最终在第二天凌晨把代码调通。现在回头看那一个晚上的收获比之后连续刷两个星期的教程都大。如果你让我说说对《21天学通C》阶段性成果测试题——hstring手写string类这个标题的整体评价我会说这是一个被严重低估的教学设计。它不像很多练习题那样只考某个孤立语法而是用一种你必须亲自从零构建一个基础工具的方式把C中最容易蒙混过关的对象生命周期、资源管理、运算符重载等核心知识全部串联起来。交作业或者自我练习时别满足于跑通再多走一步加上移动语义、验证const正确性、跑一遍内存检测、想想copy-and-swap比先释放后分配好在哪。当你把这些都做完了你会发现你不在是那个只会调用std::string的初学者而是开始用package designer的视角审视C这门语言。这才是hstring真正想教会你的东西。
