1. 项目概述从“会写”到“会设计”的C类实战最近在重温《C Primer》第七章关于类的基础部分发现很多朋友包括当年的我自己在学完构造函数、成员函数后面对“Screen类和Windows_mgr类”这个综合练习时依然会感到无从下手。这很正常因为这里不再是一个孤立的语法点而是要求你将访问控制、友元、类的作用域、类的声明与定义分离等知识串联起来去设计两个相互协作的类。这恰恰是从“会写C代码”迈向“会设计C程序”的关键一步。今天我就结合自己踩过的坑和积累的经验用一篇“一体式笔记”的形式手把手带你实现这两个类并在代码中嵌入大量“为什么这么做”的注释帮你彻底吃透面向对象设计的核心思想。简单来说这个练习模拟了一个简易的屏幕显示管理系统。Screen类代表一块屏幕它有宽、高、光标位置和屏幕内容一个字符串。Windows_mgr类则是一个窗口管理器它管理着一个Screen对象的集合比如一个桌面上的多个窗口。核心挑战在于Windows_mgr需要能清空它管理的某个Screen的内容而Screen的数据尤其是存储内容的字符串是私有的。如何让一个类操作另一个类的私有成员这就是友元friend机制大显身手的地方。通过这个练习你将深刻理解封装、友元以及类间关系的设计权衡。2. 核心需求与设计思路拆解2.1 需求场景化理解让我们先抛开书本想象一个真实的场景你正在开发一个极简的终端多窗口管理器类似tmux或screen的基础版。你有一个物理显示器对应Windows_mgr它可以同时显示多个虚拟终端窗口每个窗口对应一个Screen对象。作为管理器你至少需要能创建指定大小的新窗口Screen。在各个窗口间切换焦点移动光标。清空某个窗口的显示内容比如执行了clear命令。其中第3点就是关键。窗口内容一个std::string是每个Screen对象的私有核心数据从封装的角度看外部不应该直接操作它。但窗口管理器作为系统的“特权组件”又确实需要有清空内容的权限。在C中授予这种特定类以访问私有成员特权的机制就是友元friend。2.2 类关系与职责划分基于以上场景我们可以清晰地划分两个类的职责Screen类屏幕/窗口核心数据私有宽度(width)、高度(height)、光标当前位置(cursor)、屏幕内容字符串(contents)。核心行为公有构造一个指定大小的屏幕可能带初始内容。获取字符返回光标当前位置的字符。移动光标将光标移动到指定位置。设置字符在光标处设置指定字符并移动光标。显示内容将contents字符串按宽度换行打印到标准输出。特权开放需要将Windows_mgr类声明为友元允许其调用一个用于清空内容的私有成员函数例如clear。Windows_mgr类窗口管理器核心数据私有一个Screen对象的集合这里用std::vectorScreen来管理。核心行为公有添加一个新屏幕到集合中。清空指定编号屏幕的内容。这就是需要友元关系的地方。实现关键在Windows_mgr的clear成员函数内部它需要通过索引找到对应的Screen对象然后调用该对象的私有clear成员函数。2.3 头文件(.h/.hpp)与源文件(.cpp)的组织一个良好的C项目习惯是将类的声明接口与定义实现分离。这能加快编译速度并提高代码的模块化程度。对于这个练习我推荐如下结构// Screen.h - 声明Screen类 #pragma once #include string class Screen { // ... 成员和友元声明 }; // Windows_mgr.h - 声明Windows_mgr类需要包含Screen.h #pragma once #include Screen.h #include vector class Windows_mgr { // ... 成员声明 }; // Screen.cpp - 定义Screen类的成员函数 #include Screen.h #include iostream // ... 函数定义 // Windows_mgr.cpp - 定义Windows_mgr类的成员函数 #include Windows_mgr.h // ... 函数定义 // main.cpp - 测试程序 #include Windows_mgr.h #include iostream int main() { /* 测试代码 */ }注意由于Windows_mgr需要知道Screen的类型所以Windows_mgr.h必须#include Screen.h。而Screen.h中声明友元class Windows_mgr;时是一种前向声明告诉编译器Windows_mgr是一个类此时不需要其完整定义因此Screen.h不需要包含Windows_mgr.h。这种包含关系需要仔细设计避免循环包含。3. Screen类的逐行实现与深度注释下面我们进入实战环节。我会先给出Screen类的完整头文件并在每一处关键代码后添加详细的注释解释设计意图和语法细节。3.1 Screen类的头文件 (Screen.h)// Screen.h #pragma once // 防止头文件被多次包含的编译器指令比传统的#ifndef更简洁 #include string // 需要使用std::string存储屏幕内容 // 前向声明Windows_mgr类因为下面要将其声明为友元 // 前向声明只告诉编译器“Windows_mgr是一个类”此时不需要知道其细节 class Windows_mgr; class Screen { // 友元声明授予Windows_mgr类访问本类所有非公有成员的权限 // 位置通常在类定义的开始或结束处。这里放在开头强调其重要性。 friend class Windows_mgr; public: // 公有接口供所有用户使用 // 类型别名将std::string::size_type别名为pos用于表示位置行、列、光标索引 // 好处1. 简化书写2. 提高可读性3. 未来若要改变类型如用size_t只需改一处。 using pos std::string::size_type; // 构造函数初始化屏幕尺寸和初始内容 // 参数默认值height24, width80, contents 是常见的终端默认大小 // 成员初始化列表优先于构造函数体执行直接初始化成员效率更高。 Screen(pos ht 24, pos wd 80, char c ) : height(ht), width(wd), contents(ht * wd, c) // 用ht*wd个字符c初始化contents { // 构造函数体这里可以放一些无法通过初始化列表完成的逻辑。 // 本例中光标初始位置为0左上角。也可以在初始化列表中初始化cursor(0) cursor 0; } // 成员函数声明定义将在Screen.cpp中 char get() const; // 获取光标处字符const表示该函数不会修改对象状态 char get(pos r, pos c) const; // 重载获取指定行列的字符 Screen move(pos r, pos c); // 移动光标到指定行列返回Screen以支持链式调用(如screen.move(1,1).set(#)) Screen set(char c); // 在当前光标位置设置字符 Screen set(pos r, pos c, char ch); // 重载在指定行列设置字符 Screen display(std::ostream os); // 显示屏幕内容到输出流 const Screen display(std::ostream os) const; // const版本的重载供const对象调用 private: // 私有实现细节对外隐藏 pos cursor 0; // 光标位置索引从0开始。使用类内初始值(C11)。 pos height 0, width 0; // 屏幕高和宽 std::string contents; // 屏幕内容长度为 height * width // 一个私有工具函数用于将行列位置转换为contents中的一维索引 // 声明为const因为它不修改成员变量只是计算。 pos calc_index(pos r, pos c) const { // 注意这里假设行列从0开始计数。 // 边界检查应该在调用处如move, get进行这里为了简洁省略。 // 实际项目中应加入断言或异常处理。 return r * width c; } // 另一个私有工具函数供display函数使用用于实际执行打印操作 // 声明为const因为打印不应该改变屏幕内容。 void do_display(std::ostream os) const { for (pos i 0; i contents.size(); i) { os contents[i]; // 每到一行末尾且不是最后一行时换行 if ((i 1) % width 0 (i 1) ! contents.size()) { os \n; } } // 最后不自动加换行让调用者控制 } // 私有成员函数用于清空屏幕将contents全部设为空格 // 将被友元类Windows_mgr调用 void clear() { std::fill(contents.begin(), contents.end(), ); cursor 0; // 清空后光标复位到左上角 } };关键注释解读与避坑指南friend class Windows_mgr;这是友元声明的核心。它打破了封装因此要慎用。这里的设计理由是Windows_mgr是Screen的“管理者”二者是紧耦合的组成部分关系授予其清空权限是合理的。但请注意友元关系是单向的Screen信任Windows_mgr但反之不然且不能传递。类型别名pos使用usingC11而非typedef来定义类型别名是现代C的推荐做法它更清晰特别是在模板别名中。这里用std::string::size_type能确保索引类型与contents的索引类型完全一致避免潜在的符号或精度警告。构造函数与成员初始化列表始终优先使用初始化列表。对于contents的初始化我们使用了std::string的填充构造函数(count, char)这比在构造函数体内用循环赋值高效得多。const成员函数get和display的const版本至关重要。它们承诺不修改对象因此可以被const Screen对象调用。这是设计健壮接口的体现。calc_index私有函数这是一个典型的“提取公共操作”的重构。将行列转换索引的逻辑独立出来避免了在move、get、set等多个函数中重复编写相同的计算代码提高了可维护性。clear私有函数为什么设计成私有因为清空操作是Screen的内部状态变更外部不应随意调用。只有被授予特权的Windows_mgr才能通过友元关系调用它。这体现了“最小权限原则”。3.2 Screen类的源文件 (Screen.cpp)头文件声明了接口源文件则提供实现。// Screen.cpp #include Screen.h #include iostream // 用于std::ostream // 1. 获取光标处字符 char Screen::get() const { // 直接返回contents中cursor位置的字符。 // 这里没有做cursor越界检查因为cursor由类的其他操作维护。 // 在更健壮的实现中可以加入断言assert(cursor contents.size()); return contents[cursor]; } // 2. 重载获取指定行列字符 char Screen::get(pos r, pos c) const { // 先计算索引再返回字符。 // 注意calc_index是私有成员但同类其他成员函数可以访问。 pos index calc_index(r, c); // 同样可加入越界检查。 return contents[index]; } // 3. 移动光标 Screen Screen::move(pos r, pos c) { // 调用私有工具函数计算目标索引 cursor calc_index(r, c); // 返回本对象的引用以支持链式调用例如screen.move(1,1).set(A).move(2,2).set(B); return *this; } // 4. 在当前光标位置设置字符 Screen Screen::set(char c) { contents[cursor] c; // 设置字符 return *this; // 支持链式调用 } // 5. 重载在指定行列设置字符 Screen Screen::set(pos r, pos c, char ch) { // 先移动光标到指定位置再设置字符。直接复用move和set的逻辑。 // 注意这里调用的是move(r, c)它返回*this然后接着调用set(ch)。 // 这种写法清晰且避免了重复计算索引。 move(r, c).set(ch); // 链式调用 return *this; } // 6. 非const版本的display Screen Screen::display(std::ostream os) { // 调用私有工具函数执行实际打印 do_display(os); return *this; // 返回非const引用允许对非const对象进行链式调用 } // 7. const版本的display重载 const Screen Screen::display(std::ostream os) const { // 同样调用do_display但返回const引用 do_display(os); return *this; // 返回const引用保证const对象的常量性 }实现细节与心得链式调用设计move、set、display非const都返回Screen。这是一个非常实用的设计模式可以让代码更简洁例如myScreen.move(4,0).set(#).display(std::cout);。注意const版本的display返回const Screen这是为了保持常量性它不能用于后续的非const链式调用。代码复用注意set(pos, pos, char)的实现它巧妙地通过move(r, c).set(ch)复用了已有的逻辑。这比重新计算索引再赋值更优雅也更不容易出错。do_display私有函数的作用display函数的核心逻辑遍历打印被提取到do_display中。这样display的两个重载版本const和非const都只需调用这个公共实现避免了代码重复。这是处理const和非const成员函数共享相同实现时的常用技巧。错误处理上述实现省略了边界检查如rheight,cwidth。在真实项目中这是不严谨的。你应该在calc_index、move、get等函数中加入检查可以抛出std::out_of_range异常或者使用断言assert在调试期捕获错误。4. Windows_mgr类的实现与友元机制剖析Screen类准备就绪后我们来实现它的管理者Windows_mgr。4.1 Windows_mgr类的头文件 (Windows_mgr.h)// Windows_mgr.h #pragma once #include Screen.h // 必须包含因为要用到Screen类型 #include vector // 使用vector管理Screen集合 class Windows_mgr { public: // 类型别名方便使用 using ScreenIndex std::vectorScreen::size_type; // 构造函数初始化screens默认添加一个初始屏幕 Windows_mgr() { // 使用列表初始化screens添加一个默认的24x80屏幕 screens.push_back(Screen(24, 80, )); } // 清空指定索引处Screen的内容 // 这是核心功能需要访问Screen的私有成员函数clear() void clear(ScreenIndex i) { // 参数i是vector的索引需要检查其有效性 if (i screens.size()) { // 简单处理输出错误信息。更好的做法是抛出异常。 std::cerr Invalid screen index! std::endl; return; } // 关键行screens[i]是一个Screen对象。 // 由于Windows_mgr是Screen的友元所以可以调用其私有成员函数clear。 screens[i].clear(); // 调用Screen的私有clear函数 } // 添加一个新屏幕到管理器 Screen addScreen(const Screen s) { screens.push_back(s); return screens.back(); // 返回新添加屏幕的引用方便后续操作 } // 获取某个屏幕的引用例如用于操作该屏幕 Screen getScreen(ScreenIndex i) { // 同样应加入边界检查。这里为简洁省略。 return screens[i]; } private: // 使用vector存储Screen对象。 // 注意这里存储的是对象本身而非指针。这意味着当vector扩容时Screen对象会被移动或复制。 // 如果Screen类很大或含有不可移动的资源可能需要存储std::unique_ptrScreen。 std::vectorScreen screens; };友元机制深度解析语法与位置在Screen类内部使用friend class Windows_mgr;声明。这个声明可以放在public、protected或private区域效果都一样因为它不是成员声明。通常放在类定义的开始或结尾以示强调。单向性与非传递性友元关系是单向的。Screen把Windows_mgr当朋友所以Windows_mgr可以访问Screen的私有成员。但Windows_mgr并没有把Screen当朋友所以Screen不能访问Windows_mgr的私有成员。同时友元关系不能传递Screen的朋友的朋友并不是Screen的朋友。访问方式在Windows_mgr::clear函数中我们通过screens[i]获得一个Screen对象然后直接调用其私有函数.clear()。这看起来就像调用公有函数一样自然这正是友元赋予的特权。设计权衡友元破坏了封装增加了类之间的耦合度。因此要谨慎使用。在这个例子中Windows_mgr和Screen是紧密相关的整体组件Windows_mgr作为管理器拥有清空Screen的权限是合理的设计。另一种替代方案是在Screen中提供一个公有的clear函数但这会将清空能力暴露给所有用户可能不符合设计初衷。4.2 关于存储设计的思考Windows_mgr的私有成员screens定义为std::vectorScreen。这意味着它存储的是Screen对象。当vector需要扩容时会发生对象的复制或移动。这要求Screen类是可拷贝或可移动的。我们的Screen类包含std::string而std::string在C11后支持移动语义所以效率尚可。但在更复杂的场景下如果Screen类持有大量资源或不可拷贝的资源存储对象本身可能带来性能问题或编译错误。此时可以考虑存储智能指针例如std::vectorstd::unique_ptrScreen或std::vectorstd::shared_ptrScreen。这涉及到所有权语义的选择是另一个重要的设计话题。5. 完整测试与综合运用最后我们编写一个main.cpp来测试整个系统并演示如何使用这些类。// main.cpp #include Windows_mgr.h // 包含了Windows_mgr而Windows_mgr.h又包含了Screen.h #include iostream int main() { // 1. 创建一个窗口管理器其内部默认有一个24x80的空白屏幕 Windows_mgr mgr; // 2. 获取对第一个屏幕索引0的引用并操作它 Screen myScreen mgr.getScreen(0); myScreen.move(5, 10).set(H).set(e).set(l).set(l).set(o); // 链式调用先移动到(5,10)然后连续设置字符。注意set(char)后光标会自动后移吗 // 我们的实现中set(char)只设置当前光标字符不移动光标。所以连续set同一个位置 // 这里有个BUG连续set(H).set(e)...会在同一个位置(5,10)反复设置字符。 // 正确的操作应该是myScreen.move(5,10).set(H).move(5,11).set(e)... // 或者修改set(char)函数使其设置后光标自增这更符合“打字”的直觉。 // 我们为了演示先按有BUG的方式运行。 std::cout Screen 0 after setting Hello at (5,10):\n; myScreen.display(std::cout); // 显示屏幕内容 std::cout \n---\n; // 3. 测试获取字符 std::cout Character at (5,10) is: myScreen.get(5, 10) std::endl; // 4. 测试窗口管理器的清空功能核心友元测试 std::cout \nClearing screen 0...\n; mgr.clear(0); // 调用Windows_mgr的clear它内部调用了Screen的私有clear函数 std::cout Screen 0 after clear:\n; myScreen.display(std::cout); std::cout \n---\n; // 此时屏幕应全部为空格 // 5. 测试添加新屏幕 std::cout \nAdding a new 10x20 screen filled with *...\n; Screen newScreen(10, 20, *); Screen addedScreen mgr.addScreen(newScreen); // 添加并获取引用 std::cout New screen (index 1) content:\n; addedScreen.display(std::cout); std::cout \n---\n; // 6. 清空新屏幕 std::cout \nClearing the new screen (index 1)...\n; mgr.clear(1); std::cout New screen after clear:\n; addedScreen.display(std::cout); std::cout std::endl; return 0; }测试结果分析与问题修正运行上述程序你会发现输出可能不符合预期因为我们在main函数中发现了set操作的逻辑BUG。这引出了一个重要的设计点光标的行为。在我们的初始设计中set(char)函数只替换光标处的字符不移动光标。这类似于文本编辑器的“覆盖模式”。而更常见的终端行为是“插入模式”即输入一个字符后光标移动到下一个位置。我们应该修改Screen::set(char)的实现// 在Screen.cpp中修改set(char)函数 Screen Screen::set(char c) { contents[cursor] c; cursor; // 新增设置字符后光标自动后移一位 // 注意这里应该检查cursor是否越界 contents.size()如果越界可以将其置为末尾。 if (cursor contents.size()) { cursor contents.size() - 1; } return *this; }同时set(pos, pos, char)函数因为调用了move和set(char)所以也会继承这个“设置并后移”的行为这通常是合理的。修改后main函数中的链式调用myScreen.move(5,10).set(H).set(e)...就能正确地在(5,10), (5,11), ... 位置依次设置字符了。6. 常见问题、扩展思考与避坑总结6.1 编译与链接问题问题分开编译时出现“未定义的引用”错误。原因Screen.cpp和Windows_mgr.cpp没有参与编译链接。解决确保你的编译命令包含了所有源文件。例如使用gg -stdc11 -o screen_app main.cpp Screen.cpp Windows_mgr.cpp。如果使用IDE如VS Code with CMake/MSVC, CLion, Visual Studio请确保项目配置中添加了所有.cpp文件。6.2 友元使用的陷阱过度使用不要因为方便就滥用友元。优先考虑通过公有接口成员函数进行交互。友元应仅用于表示紧密的、逻辑上的协作关系。循环依赖如果ClassA需要是ClassB的友元ClassB也需要是ClassA的友元这可能暗示设计有问题需要重新审视类的职责划分。前向声明在Screen.h中我们使用了class Windows_mgr;的前向声明。这是因为在声明友元时编译器只需要知道这个名字是一个类。如果Screen的方法需要用到Windows_mgr的类型例如作为参数类型则必须包含完整的头文件。6.3 设计扩展思考const正确性我们为display提供了const和非const的重载。对于get函数是否也需要通常get是获取信息不修改对象所以应该声明为const。我们已经这样做了。移动光标move的边界处理当前的move函数没有检查输入的行列值是否有效。一个健壮的实现应该在calc_index或move内部进行检查并采取相应措施如抛出异常、静默截断到边界等。Windows_mgr的功能扩展可以添加更多功能如removeScreen、swapScreens、getCurrentScreen管理当前焦点窗口等。使用智能指针管理Screen如前所述如果Screen对象很大或复制成本高Windows_mgr可以改为管理std::unique_ptrScreen。这时clear函数内部需要解引用指针screens[i]-clear();。返回引用也需要调整return *screens[i];。将clear作为公有函数这是一个设计选择。如果清空屏幕是一个合理的、通用的操作将其设为Screen的公有函数也未尝不可。但本练习的目的正是为了演示友元的使用场景。6.4 个人实操心得先画图再写码在实现这类有关联的类之前用纸笔画一下它们的关系图UML类图简版明确谁拥有谁谁需要访问谁的私有成员能极大减少设计错误。小步快跑频繁测试不要一次性写完所有代码。可以先实现Screen的基本功能构造、get、move写个简单的main测试。然后再加set再测试。最后实现Windows_mgr和友元。每步都测试能快速定位问题。重视编译器警告将编译器警告级别调高如g的-Wall -Wextra -pedantic。警告往往预示着潜在的问题比如类型转换、未使用的变量等。注释是为“为什么”而写代码中的注释不应重复“是什么”代码已经表达了而应解释“为什么这么做”。例如为什么这里用友元为什么这个函数返回引用这些决策背后的思考才是注释的价值所在。理解链式调用的代价链式调用obj.func1().func2().func3()看起来很酷但要注意每个函数都返回引用这意味着它们必须正确处理好对象的状态。同时调试时可能不如分步调用直观。通过这个从零开始的实现过程相信你对C类的封装、友元、const成员函数、接口设计以及多文件项目组织有了更立体、更深刻的理解。这不仅仅是完成书后练习更是培养扎实的面向对象设计与实现能力的绝佳训练。
1. 项目概述从“会写”到“会设计”的C类实战最近在重温《C Primer》第七章关于类的基础部分发现很多朋友包括当年的我自己在学完构造函数、成员函数后面对“Screen类和Windows_mgr类”这个综合练习时依然会感到无从下手。这很正常因为这里不再是一个孤立的语法点而是要求你将访问控制、友元、类的作用域、类的声明与定义分离等知识串联起来去设计两个相互协作的类。这恰恰是从“会写C代码”迈向“会设计C程序”的关键一步。今天我就结合自己踩过的坑和积累的经验用一篇“一体式笔记”的形式手把手带你实现这两个类并在代码中嵌入大量“为什么这么做”的注释帮你彻底吃透面向对象设计的核心思想。简单来说这个练习模拟了一个简易的屏幕显示管理系统。Screen类代表一块屏幕它有宽、高、光标位置和屏幕内容一个字符串。Windows_mgr类则是一个窗口管理器它管理着一个Screen对象的集合比如一个桌面上的多个窗口。核心挑战在于Windows_mgr需要能清空它管理的某个Screen的内容而Screen的数据尤其是存储内容的字符串是私有的。如何让一个类操作另一个类的私有成员这就是友元friend机制大显身手的地方。通过这个练习你将深刻理解封装、友元以及类间关系的设计权衡。2. 核心需求与设计思路拆解2.1 需求场景化理解让我们先抛开书本想象一个真实的场景你正在开发一个极简的终端多窗口管理器类似tmux或screen的基础版。你有一个物理显示器对应Windows_mgr它可以同时显示多个虚拟终端窗口每个窗口对应一个Screen对象。作为管理器你至少需要能创建指定大小的新窗口Screen。在各个窗口间切换焦点移动光标。清空某个窗口的显示内容比如执行了clear命令。其中第3点就是关键。窗口内容一个std::string是每个Screen对象的私有核心数据从封装的角度看外部不应该直接操作它。但窗口管理器作为系统的“特权组件”又确实需要有清空内容的权限。在C中授予这种特定类以访问私有成员特权的机制就是友元friend。2.2 类关系与职责划分基于以上场景我们可以清晰地划分两个类的职责Screen类屏幕/窗口核心数据私有宽度(width)、高度(height)、光标当前位置(cursor)、屏幕内容字符串(contents)。核心行为公有构造一个指定大小的屏幕可能带初始内容。获取字符返回光标当前位置的字符。移动光标将光标移动到指定位置。设置字符在光标处设置指定字符并移动光标。显示内容将contents字符串按宽度换行打印到标准输出。特权开放需要将Windows_mgr类声明为友元允许其调用一个用于清空内容的私有成员函数例如clear。Windows_mgr类窗口管理器核心数据私有一个Screen对象的集合这里用std::vectorScreen来管理。核心行为公有添加一个新屏幕到集合中。清空指定编号屏幕的内容。这就是需要友元关系的地方。实现关键在Windows_mgr的clear成员函数内部它需要通过索引找到对应的Screen对象然后调用该对象的私有clear成员函数。2.3 头文件(.h/.hpp)与源文件(.cpp)的组织一个良好的C项目习惯是将类的声明接口与定义实现分离。这能加快编译速度并提高代码的模块化程度。对于这个练习我推荐如下结构// Screen.h - 声明Screen类 #pragma once #include string class Screen { // ... 成员和友元声明 }; // Windows_mgr.h - 声明Windows_mgr类需要包含Screen.h #pragma once #include Screen.h #include vector class Windows_mgr { // ... 成员声明 }; // Screen.cpp - 定义Screen类的成员函数 #include Screen.h #include iostream // ... 函数定义 // Windows_mgr.cpp - 定义Windows_mgr类的成员函数 #include Windows_mgr.h // ... 函数定义 // main.cpp - 测试程序 #include Windows_mgr.h #include iostream int main() { /* 测试代码 */ }注意由于Windows_mgr需要知道Screen的类型所以Windows_mgr.h必须#include Screen.h。而Screen.h中声明友元class Windows_mgr;时是一种前向声明告诉编译器Windows_mgr是一个类此时不需要其完整定义因此Screen.h不需要包含Windows_mgr.h。这种包含关系需要仔细设计避免循环包含。3. Screen类的逐行实现与深度注释下面我们进入实战环节。我会先给出Screen类的完整头文件并在每一处关键代码后添加详细的注释解释设计意图和语法细节。3.1 Screen类的头文件 (Screen.h)// Screen.h #pragma once // 防止头文件被多次包含的编译器指令比传统的#ifndef更简洁 #include string // 需要使用std::string存储屏幕内容 // 前向声明Windows_mgr类因为下面要将其声明为友元 // 前向声明只告诉编译器“Windows_mgr是一个类”此时不需要知道其细节 class Windows_mgr; class Screen { // 友元声明授予Windows_mgr类访问本类所有非公有成员的权限 // 位置通常在类定义的开始或结束处。这里放在开头强调其重要性。 friend class Windows_mgr; public: // 公有接口供所有用户使用 // 类型别名将std::string::size_type别名为pos用于表示位置行、列、光标索引 // 好处1. 简化书写2. 提高可读性3. 未来若要改变类型如用size_t只需改一处。 using pos std::string::size_type; // 构造函数初始化屏幕尺寸和初始内容 // 参数默认值height24, width80, contents 是常见的终端默认大小 // 成员初始化列表优先于构造函数体执行直接初始化成员效率更高。 Screen(pos ht 24, pos wd 80, char c ) : height(ht), width(wd), contents(ht * wd, c) // 用ht*wd个字符c初始化contents { // 构造函数体这里可以放一些无法通过初始化列表完成的逻辑。 // 本例中光标初始位置为0左上角。也可以在初始化列表中初始化cursor(0) cursor 0; } // 成员函数声明定义将在Screen.cpp中 char get() const; // 获取光标处字符const表示该函数不会修改对象状态 char get(pos r, pos c) const; // 重载获取指定行列的字符 Screen move(pos r, pos c); // 移动光标到指定行列返回Screen以支持链式调用(如screen.move(1,1).set(#)) Screen set(char c); // 在当前光标位置设置字符 Screen set(pos r, pos c, char ch); // 重载在指定行列设置字符 Screen display(std::ostream os); // 显示屏幕内容到输出流 const Screen display(std::ostream os) const; // const版本的重载供const对象调用 private: // 私有实现细节对外隐藏 pos cursor 0; // 光标位置索引从0开始。使用类内初始值(C11)。 pos height 0, width 0; // 屏幕高和宽 std::string contents; // 屏幕内容长度为 height * width // 一个私有工具函数用于将行列位置转换为contents中的一维索引 // 声明为const因为它不修改成员变量只是计算。 pos calc_index(pos r, pos c) const { // 注意这里假设行列从0开始计数。 // 边界检查应该在调用处如move, get进行这里为了简洁省略。 // 实际项目中应加入断言或异常处理。 return r * width c; } // 另一个私有工具函数供display函数使用用于实际执行打印操作 // 声明为const因为打印不应该改变屏幕内容。 void do_display(std::ostream os) const { for (pos i 0; i contents.size(); i) { os contents[i]; // 每到一行末尾且不是最后一行时换行 if ((i 1) % width 0 (i 1) ! contents.size()) { os \n; } } // 最后不自动加换行让调用者控制 } // 私有成员函数用于清空屏幕将contents全部设为空格 // 将被友元类Windows_mgr调用 void clear() { std::fill(contents.begin(), contents.end(), ); cursor 0; // 清空后光标复位到左上角 } };关键注释解读与避坑指南friend class Windows_mgr;这是友元声明的核心。它打破了封装因此要慎用。这里的设计理由是Windows_mgr是Screen的“管理者”二者是紧耦合的组成部分关系授予其清空权限是合理的。但请注意友元关系是单向的Screen信任Windows_mgr但反之不然且不能传递。类型别名pos使用usingC11而非typedef来定义类型别名是现代C的推荐做法它更清晰特别是在模板别名中。这里用std::string::size_type能确保索引类型与contents的索引类型完全一致避免潜在的符号或精度警告。构造函数与成员初始化列表始终优先使用初始化列表。对于contents的初始化我们使用了std::string的填充构造函数(count, char)这比在构造函数体内用循环赋值高效得多。const成员函数get和display的const版本至关重要。它们承诺不修改对象因此可以被const Screen对象调用。这是设计健壮接口的体现。calc_index私有函数这是一个典型的“提取公共操作”的重构。将行列转换索引的逻辑独立出来避免了在move、get、set等多个函数中重复编写相同的计算代码提高了可维护性。clear私有函数为什么设计成私有因为清空操作是Screen的内部状态变更外部不应随意调用。只有被授予特权的Windows_mgr才能通过友元关系调用它。这体现了“最小权限原则”。3.2 Screen类的源文件 (Screen.cpp)头文件声明了接口源文件则提供实现。// Screen.cpp #include Screen.h #include iostream // 用于std::ostream // 1. 获取光标处字符 char Screen::get() const { // 直接返回contents中cursor位置的字符。 // 这里没有做cursor越界检查因为cursor由类的其他操作维护。 // 在更健壮的实现中可以加入断言assert(cursor contents.size()); return contents[cursor]; } // 2. 重载获取指定行列字符 char Screen::get(pos r, pos c) const { // 先计算索引再返回字符。 // 注意calc_index是私有成员但同类其他成员函数可以访问。 pos index calc_index(r, c); // 同样可加入越界检查。 return contents[index]; } // 3. 移动光标 Screen Screen::move(pos r, pos c) { // 调用私有工具函数计算目标索引 cursor calc_index(r, c); // 返回本对象的引用以支持链式调用例如screen.move(1,1).set(A).move(2,2).set(B); return *this; } // 4. 在当前光标位置设置字符 Screen Screen::set(char c) { contents[cursor] c; // 设置字符 return *this; // 支持链式调用 } // 5. 重载在指定行列设置字符 Screen Screen::set(pos r, pos c, char ch) { // 先移动光标到指定位置再设置字符。直接复用move和set的逻辑。 // 注意这里调用的是move(r, c)它返回*this然后接着调用set(ch)。 // 这种写法清晰且避免了重复计算索引。 move(r, c).set(ch); // 链式调用 return *this; } // 6. 非const版本的display Screen Screen::display(std::ostream os) { // 调用私有工具函数执行实际打印 do_display(os); return *this; // 返回非const引用允许对非const对象进行链式调用 } // 7. const版本的display重载 const Screen Screen::display(std::ostream os) const { // 同样调用do_display但返回const引用 do_display(os); return *this; // 返回const引用保证const对象的常量性 }实现细节与心得链式调用设计move、set、display非const都返回Screen。这是一个非常实用的设计模式可以让代码更简洁例如myScreen.move(4,0).set(#).display(std::cout);。注意const版本的display返回const Screen这是为了保持常量性它不能用于后续的非const链式调用。代码复用注意set(pos, pos, char)的实现它巧妙地通过move(r, c).set(ch)复用了已有的逻辑。这比重新计算索引再赋值更优雅也更不容易出错。do_display私有函数的作用display函数的核心逻辑遍历打印被提取到do_display中。这样display的两个重载版本const和非const都只需调用这个公共实现避免了代码重复。这是处理const和非const成员函数共享相同实现时的常用技巧。错误处理上述实现省略了边界检查如rheight,cwidth。在真实项目中这是不严谨的。你应该在calc_index、move、get等函数中加入检查可以抛出std::out_of_range异常或者使用断言assert在调试期捕获错误。4. Windows_mgr类的实现与友元机制剖析Screen类准备就绪后我们来实现它的管理者Windows_mgr。4.1 Windows_mgr类的头文件 (Windows_mgr.h)// Windows_mgr.h #pragma once #include Screen.h // 必须包含因为要用到Screen类型 #include vector // 使用vector管理Screen集合 class Windows_mgr { public: // 类型别名方便使用 using ScreenIndex std::vectorScreen::size_type; // 构造函数初始化screens默认添加一个初始屏幕 Windows_mgr() { // 使用列表初始化screens添加一个默认的24x80屏幕 screens.push_back(Screen(24, 80, )); } // 清空指定索引处Screen的内容 // 这是核心功能需要访问Screen的私有成员函数clear() void clear(ScreenIndex i) { // 参数i是vector的索引需要检查其有效性 if (i screens.size()) { // 简单处理输出错误信息。更好的做法是抛出异常。 std::cerr Invalid screen index! std::endl; return; } // 关键行screens[i]是一个Screen对象。 // 由于Windows_mgr是Screen的友元所以可以调用其私有成员函数clear。 screens[i].clear(); // 调用Screen的私有clear函数 } // 添加一个新屏幕到管理器 Screen addScreen(const Screen s) { screens.push_back(s); return screens.back(); // 返回新添加屏幕的引用方便后续操作 } // 获取某个屏幕的引用例如用于操作该屏幕 Screen getScreen(ScreenIndex i) { // 同样应加入边界检查。这里为简洁省略。 return screens[i]; } private: // 使用vector存储Screen对象。 // 注意这里存储的是对象本身而非指针。这意味着当vector扩容时Screen对象会被移动或复制。 // 如果Screen类很大或含有不可移动的资源可能需要存储std::unique_ptrScreen。 std::vectorScreen screens; };友元机制深度解析语法与位置在Screen类内部使用friend class Windows_mgr;声明。这个声明可以放在public、protected或private区域效果都一样因为它不是成员声明。通常放在类定义的开始或结尾以示强调。单向性与非传递性友元关系是单向的。Screen把Windows_mgr当朋友所以Windows_mgr可以访问Screen的私有成员。但Windows_mgr并没有把Screen当朋友所以Screen不能访问Windows_mgr的私有成员。同时友元关系不能传递Screen的朋友的朋友并不是Screen的朋友。访问方式在Windows_mgr::clear函数中我们通过screens[i]获得一个Screen对象然后直接调用其私有函数.clear()。这看起来就像调用公有函数一样自然这正是友元赋予的特权。设计权衡友元破坏了封装增加了类之间的耦合度。因此要谨慎使用。在这个例子中Windows_mgr和Screen是紧密相关的整体组件Windows_mgr作为管理器拥有清空Screen的权限是合理的设计。另一种替代方案是在Screen中提供一个公有的clear函数但这会将清空能力暴露给所有用户可能不符合设计初衷。4.2 关于存储设计的思考Windows_mgr的私有成员screens定义为std::vectorScreen。这意味着它存储的是Screen对象。当vector需要扩容时会发生对象的复制或移动。这要求Screen类是可拷贝或可移动的。我们的Screen类包含std::string而std::string在C11后支持移动语义所以效率尚可。但在更复杂的场景下如果Screen类持有大量资源或不可拷贝的资源存储对象本身可能带来性能问题或编译错误。此时可以考虑存储智能指针例如std::vectorstd::unique_ptrScreen或std::vectorstd::shared_ptrScreen。这涉及到所有权语义的选择是另一个重要的设计话题。5. 完整测试与综合运用最后我们编写一个main.cpp来测试整个系统并演示如何使用这些类。// main.cpp #include Windows_mgr.h // 包含了Windows_mgr而Windows_mgr.h又包含了Screen.h #include iostream int main() { // 1. 创建一个窗口管理器其内部默认有一个24x80的空白屏幕 Windows_mgr mgr; // 2. 获取对第一个屏幕索引0的引用并操作它 Screen myScreen mgr.getScreen(0); myScreen.move(5, 10).set(H).set(e).set(l).set(l).set(o); // 链式调用先移动到(5,10)然后连续设置字符。注意set(char)后光标会自动后移吗 // 我们的实现中set(char)只设置当前光标字符不移动光标。所以连续set同一个位置 // 这里有个BUG连续set(H).set(e)...会在同一个位置(5,10)反复设置字符。 // 正确的操作应该是myScreen.move(5,10).set(H).move(5,11).set(e)... // 或者修改set(char)函数使其设置后光标自增这更符合“打字”的直觉。 // 我们为了演示先按有BUG的方式运行。 std::cout Screen 0 after setting Hello at (5,10):\n; myScreen.display(std::cout); // 显示屏幕内容 std::cout \n---\n; // 3. 测试获取字符 std::cout Character at (5,10) is: myScreen.get(5, 10) std::endl; // 4. 测试窗口管理器的清空功能核心友元测试 std::cout \nClearing screen 0...\n; mgr.clear(0); // 调用Windows_mgr的clear它内部调用了Screen的私有clear函数 std::cout Screen 0 after clear:\n; myScreen.display(std::cout); std::cout \n---\n; // 此时屏幕应全部为空格 // 5. 测试添加新屏幕 std::cout \nAdding a new 10x20 screen filled with *...\n; Screen newScreen(10, 20, *); Screen addedScreen mgr.addScreen(newScreen); // 添加并获取引用 std::cout New screen (index 1) content:\n; addedScreen.display(std::cout); std::cout \n---\n; // 6. 清空新屏幕 std::cout \nClearing the new screen (index 1)...\n; mgr.clear(1); std::cout New screen after clear:\n; addedScreen.display(std::cout); std::cout std::endl; return 0; }测试结果分析与问题修正运行上述程序你会发现输出可能不符合预期因为我们在main函数中发现了set操作的逻辑BUG。这引出了一个重要的设计点光标的行为。在我们的初始设计中set(char)函数只替换光标处的字符不移动光标。这类似于文本编辑器的“覆盖模式”。而更常见的终端行为是“插入模式”即输入一个字符后光标移动到下一个位置。我们应该修改Screen::set(char)的实现// 在Screen.cpp中修改set(char)函数 Screen Screen::set(char c) { contents[cursor] c; cursor; // 新增设置字符后光标自动后移一位 // 注意这里应该检查cursor是否越界 contents.size()如果越界可以将其置为末尾。 if (cursor contents.size()) { cursor contents.size() - 1; } return *this; }同时set(pos, pos, char)函数因为调用了move和set(char)所以也会继承这个“设置并后移”的行为这通常是合理的。修改后main函数中的链式调用myScreen.move(5,10).set(H).set(e)...就能正确地在(5,10), (5,11), ... 位置依次设置字符了。6. 常见问题、扩展思考与避坑总结6.1 编译与链接问题问题分开编译时出现“未定义的引用”错误。原因Screen.cpp和Windows_mgr.cpp没有参与编译链接。解决确保你的编译命令包含了所有源文件。例如使用gg -stdc11 -o screen_app main.cpp Screen.cpp Windows_mgr.cpp。如果使用IDE如VS Code with CMake/MSVC, CLion, Visual Studio请确保项目配置中添加了所有.cpp文件。6.2 友元使用的陷阱过度使用不要因为方便就滥用友元。优先考虑通过公有接口成员函数进行交互。友元应仅用于表示紧密的、逻辑上的协作关系。循环依赖如果ClassA需要是ClassB的友元ClassB也需要是ClassA的友元这可能暗示设计有问题需要重新审视类的职责划分。前向声明在Screen.h中我们使用了class Windows_mgr;的前向声明。这是因为在声明友元时编译器只需要知道这个名字是一个类。如果Screen的方法需要用到Windows_mgr的类型例如作为参数类型则必须包含完整的头文件。6.3 设计扩展思考const正确性我们为display提供了const和非const的重载。对于get函数是否也需要通常get是获取信息不修改对象所以应该声明为const。我们已经这样做了。移动光标move的边界处理当前的move函数没有检查输入的行列值是否有效。一个健壮的实现应该在calc_index或move内部进行检查并采取相应措施如抛出异常、静默截断到边界等。Windows_mgr的功能扩展可以添加更多功能如removeScreen、swapScreens、getCurrentScreen管理当前焦点窗口等。使用智能指针管理Screen如前所述如果Screen对象很大或复制成本高Windows_mgr可以改为管理std::unique_ptrScreen。这时clear函数内部需要解引用指针screens[i]-clear();。返回引用也需要调整return *screens[i];。将clear作为公有函数这是一个设计选择。如果清空屏幕是一个合理的、通用的操作将其设为Screen的公有函数也未尝不可。但本练习的目的正是为了演示友元的使用场景。6.4 个人实操心得先画图再写码在实现这类有关联的类之前用纸笔画一下它们的关系图UML类图简版明确谁拥有谁谁需要访问谁的私有成员能极大减少设计错误。小步快跑频繁测试不要一次性写完所有代码。可以先实现Screen的基本功能构造、get、move写个简单的main测试。然后再加set再测试。最后实现Windows_mgr和友元。每步都测试能快速定位问题。重视编译器警告将编译器警告级别调高如g的-Wall -Wextra -pedantic。警告往往预示着潜在的问题比如类型转换、未使用的变量等。注释是为“为什么”而写代码中的注释不应重复“是什么”代码已经表达了而应解释“为什么这么做”。例如为什么这里用友元为什么这个函数返回引用这些决策背后的思考才是注释的价值所在。理解链式调用的代价链式调用obj.func1().func2().func3()看起来很酷但要注意每个函数都返回引用这意味着它们必须正确处理好对象的状态。同时调试时可能不如分步调用直观。通过这个从零开始的实现过程相信你对C类的封装、友元、const成员函数、接口设计以及多文件项目组织有了更立体、更深刻的理解。这不仅仅是完成书后练习更是培养扎实的面向对象设计与实现能力的绝佳训练。
)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
