m0_37581770的博客

core dump 定位segment fault错误思路：一般是使用gdb进行问题定位，gdb需要有core-dump文件。 方法： 设置core-dump文件大小，默认是0，ulimit -c unlimited，设置corefile的大小为不限制大小; 编译可执行程序时，需要加上-g选项，便于后期问题定位; 修改corefile的输出路径，新建一个/corefile文件夹，然后输入chmod 777开设权限; 通过echo “/corefile/core-%e-%p-%t” > /proc/sy

必要的前提环境 vscode安装C/C++插件 开发机安装gdb 远程调试则远程运行机需要gdbserver 代码编译增加 -g 选项，建议采用-O0的优化等级 注意事项： 对于使用setcap提升权限的app，直接调试是没有权限的。 可以给/usr/bin/gdbserver提升权限后，来进行本地调试。（不建议使用root运行vscode来调试，会导致代码文件变更为root权限） 给gdb提升权限，仅在单独使用gdb调试时才有效，使用vscode调试仍旧没用 调试配置 在根目录下的【.vscode

CMake 基本结构 cmake_minimum_required(VERSION 3.0) project(ttest) # 单元测试 # add_subdirectory(test) # add_subdirectory(subsrc) # 目标编译配置 include_directories( ) aux_source_directory(. SRCS) add_executable(${PROJECT_NAME} ${SRCS} ) # 动态库 # add_library(${P

继承（泛化） 实现 依赖 关联 聚合 关联和聚合基本一致。其中A中B都拥有独立的生命周期 组合 A生命周期结束。B、C也结束

喜欢由一流人才组成的小型、精干的队伍，而不是那些几百人的大型团队。 1. 问题：如何在有意的进度安排内创建大型的系统？ 作者观点：需要协同沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不但引起的不良结果 小型精干队伍对于真正意义上的大型系统，它太慢了。 矛盾：对于效率和概念的完整性，最好由少数干练的人员来设计和开发 VS 对于大型系统，需要大量人手，以使产品...

1. 进度滞后的原因 不真实的假设—一切都将运作良好 假设人和月可以互换，将进度与工作量相互混淆 缺少耐心持续估算工作 缺少对进度的跟踪和监督 进度滞后，盲目增加人手 2. 乐观主义 系统编程的进度安排背后的第一个错误假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的事件 文中提到“对于创造者，只有在实现过程中，才能发现我们构思的不完整性和不一致性。” 可以引申理解为设计时的乐...

1. 焦油坑 1.1 编程系统产品的演进 程序：完整的能够在作者所在系统平台上运行的产品 编程产品：可被任何人运行、测试、修复和扩展的程序。其需按照普遍认可的风格来编写，且需要彻底的测试来确保稳定性和可靠性（依赖于详尽的测试用例库）。此外还需要晚辈的文档。 编程系统：在功能上能够相互写作、具有规范的格式、可以进行交互的程序集合，并用来组装和搭建整个系统。其每个程序都要按照要求编制，是的输入输出接...