Linux CMake 自动生成模板:一键清理、零警告编译、多库链接
导言在 Linux 下用 CMake 管理 C++ 项目时,你是否常遇到这些问题:手动写 CMakeLists.txt 繁琐、旧配置文件干扰编译、未使用参数警告刷屏、链接库不知从何下手?本文将带你打造一个「全能型 CMake 自动生成模板」,一键解决上述所有痛点,让项目构建效率翻倍。 一、模板核心功能清单先看这个模板能帮我们做什么,避免重复造轮子: 自动清理旧文件:运行时自动删除 CMake 缓存、旧 Makefile 等冗余文件,杜绝配置冲突 智能扫描源码:递归识别当前目录及子目录下所有.cpp/.cc/.h/.hpp文件,无需手动列文件 零警告编译:默认抑制unused parameter(未使用参数)警告,同时保留关键编译检查 规范输出目录:可执行文件、库文件分别输出到build/bin和build/lib,源码目录不污染源 灵活链接库:预留动态库(.so)和静态库(.a)链接区域,示例清晰 安全项目命名:避免中文 /...
文件词频代码解析
一、项目总览:结构与核心目标1.1 项目定位该程序是一款轻量级文本分析工具,支持加载文本文件、单词搜索及布尔逻辑运算,核心目标是快速定位单词在文本中的出现位置,并通过逻辑组合满足复杂搜索需求(如 “查找同时包含hello和world的行”)。在实际应用场景中,无论是处理学术论文、代码库检索,还是进行日志文件分析,该工具都能通过高效的搜索逻辑,快速定位关键信息,极大提升文本处理效率。 1.2 文件结构123456789word_frequency_analysis/├── 22.txt/text.txt # 测试文本文件├── CMakeLists.txt # CMake构建配置(依赖C++11及以上)├── main.cpp # 程序入口(命令循环与交互)├── my_operation.h # 运算类声明(Operation基类)├── operation.cpp # 运算工厂实现(Processing类)├── programbegin.cpp #...
文件词频统计系统设计
一、文本查询程序代码整理1.1 textsearchprogram.h123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475#ifndef TEXT_SEARCH_PROGRAM_H#define TEXT_SEARCH_PROGRAM_H#include "my_operation.h"void cleanWord(string & word);//包括单词出现次数和出现行号class WordDate {private: int count = 0; set <int> linenums; friend class ProgramDate;public: WordDate () {}; WordDate (int _count, set...
Leetcode 0078. Subsets
78. SubsetsGiven an integer array nums of unique elements, return all possible subsets (the power set). The solution set must not contain duplicate subsets. Return the solution in any order. Example 1: 12Input: nums = [1,2,3]Output: [[],[1],[2],[1,2],[3],[1,3],[2,3],[1,2,3]] Example 2: 12Input: nums = [0]Output: [[],[0]] 题目大意给定一个无重复元素的整数数组 nums,返回该数组所有可能的子集(即幂集)。幂集需包含所有可能的子集(包括空集和数组本身),且不能有重复子集,结果顺序可任意。 例如: 输入 nums = [1,2,3],输出 [[],[1],[2],[1,2],[3],[1,3],[2,3],[1,2,3]](共 2³=8...
Leetcode 0093. Restore IP Addresses
93. Restore IP AddressesA valid IP address consists of exactly four integers separated by single dots. Each integer is between 0 and 255 (inclusive) and cannot have leading zeros. For example, "0.1.2.201" and "192.168.1.1" are valid IP addresses, but "0.011.255.245", "192.168.1.312" and "192.168@1.1" are invalid IP addresses. Given a string s containing only digits, return all possible valid IP addresses that can be formed by inserting dots...
Leetcode 0131. Palindrome Partitioning
131. Palindrome PartitioningGiven a string s, partition s such that every substring of the partition is a palindrome. Return all possible palindrome partitioning of s. Example 1: 12Input: s = "aab"Output: [["a","a","b"],["aa","b"]] Example 2: 12Input: s = "a"Output: [["a"]] 题目大意给定一个字符串 s,将其分割成若干个子串,使得每个子串都是回文串。返回所有可能的分割方案。 例如: 输入 s = "aab",输出...
责任链模式
一、责任链模式原理说明1.1 模式定义根据《大话设计模式》定义,责任链模式(Chain of Responsibility Pattern) 是一种对象行为型模式,它使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 1.2 模式结构责任链模式包含以下核心角色,各角色职责明确且协同工作: 角色名称 核心职责 典型实现方式 抽象处理者(Handler) 定义处理请求的接口,包含抽象处理方法和一个后继连接 抽象类或纯虚函数接口 具体处理者(ConcreteHandler) 实现抽象处理者的接口,判断能否处理当前请求;若能则处理,否则将请求转发给后继者 继承抽象处理者的具体类 客户端(Client) 创建处理链,并向链头的具体处理者提交请求,不关心请求的处理细节和传递过程 主函数或业务逻辑模块 1.3...
观察者模式
一、模式核心原理1.1 模式定义观察者模式(Observer Pattern)是一种行为型设计模式,定义了对象间一对多的依赖关系,当一个对象(被观察者)的状态发生改变时,所有依赖于它的对象(观察者)都会自动收到通知并更新。 该模式的核心价值在于解耦被观察者与观察者: 被观察者无需知道具体观察者的类型和实现 观察者可独立添加 / 移除,不影响被观察者核心逻辑 支持事件驱动架构的灵活扩展 1.2 UML 类图结构观察者模式包含四个核心角色: 角色 职责 典型实现 Subject(抽象被观察者) 定义观察者管理接口(注册 / 移除 / 通知) 抽象基类 ConcreteSubject(具体被观察者) 维护状态,状态变化时通知所有观察者 继承 Subject 的具体类 Observer(抽象观察者) 定义更新接口,供被观察者通知时调用 抽象基类 ConcreteObserver(具体观察者) 实现更新接口,处理被观察者的通知 继承 Observer...
抽象工厂模式
一、工厂方法模式的局限性工厂方法模式仅能创建单一产品等级结构的对象,当系统需要创建多个相互关联的产品族时,工厂方法模式便显现出明显不足。例如,在开发跨平台 UI 组件时,需要同时创建 Windows 风格的按钮和文本框,以及 macOS 风格的按钮和文本框,这些按钮和文本框分别构成不同的产品族。若使用工厂方法模式,需为每个产品(按钮、文本框)都创建对应的工厂类,会导致类的数量急剧增加,且难以保证同一产品族内产品的一致性。而抽象工厂模式恰好能解决这一问题,它可提供一个接口,用于创建一系列相关或相互依赖的对象,无需指定它们的具体类。 二、抽象工厂模式结构2.1 结构文字描述抽象工厂模式包含四个核心角色: 抽象工厂(Abstract Factory):声明一组用于创建一族产品的方法,每个方法对应一种产品。 具体工厂(Concrete Factory):实现抽象工厂中声明的创建产品的方法,生成具体的产品对象,一个具体工厂对应一个产品族。 抽象产品(Abstract Product):为每种产品声明接口,定义产品的公共方法。 具体产品(Concrete...
Leetcode 0040. Combination Sum II
40. Combination Sum IIGiven a collection of candidate numbers (candidates) and a target number (target), find all unique combinations in candidates where the candidate numbers sum to target. Each number in candidates may only be used once in the combination. Note: The solution set must not contain duplicate combinations. Example 1: 12345678Input: candidates = [10,1,2,7,6,1,5], target = 8Output: [[1,1,6],[1,2,5],[1,7],[2,6]] Example 2: 123456Input: candidates = [2,5,2,1,2], target =...
Leetcode 0039. Combination Sum
39. Combination SumGiven an array of distinct integers candidates and a target integer target, return a list of all unique combinations of candidates where the chosen numbers sum to target. You may return the combinations in any order. The same number may be chosen from candidates an unlimited number of times. Two combinations are unique if the frequency of at least one of the chosen numbers is different. The test cases are generated such that the number of unique combinations that sum up to...
Leetcode 0216. Combination Sum III
216. Combination Sum IIIFind all valid combinations of k numbers that sum up to n such that the following conditions are true: Only numbers 1 through 9 are used. Each number is used at most once. Return a list of all possible valid combinations. The list must not contain the same combination twice, and the combinations may be returned in any order. Example 1: 12345Input: k = 3, n = 7Output: [[1,2,4]]Explanation:1 + 2 + 4 = 7There are no other valid combinations. Example 2: 1234567Input: k...
C++ 类间关系与功能复用
导言在面向对象编程的世界里,类与类之间的关系设计和功能复用机制是构建高质量软件的基石。理解这些概念不仅有助于写出结构清晰的代码,更能提升系统的可维护性和扩展性。本文将结合实例,深入探讨 C++ 中类间的五大关系(继承、组合、聚合、关联、依赖),并分享对功能复用的理解与实践经验。 一、对类间关系的本质理解类间关系本质上反映了现实世界中事物之间的联系,是对客观世界的抽象。在面向对象设计中,我们通过类间关系来建模这些联系,使软件系统更贴近现实逻辑。 类间关系并非孤立存在,它们之间存在着从强耦合到弱耦合的渐变过程:继承 > 组合 > 聚合 > 关联 > 依赖。这种耦合度的差异,决定了它们在不同场景下的适用性。 让我们以基础类 A 为核心,通过具体代码来理解这些关系: 123456789class A{public: friend class E; void func() { cout << "hello,world" << endl; ...
策略模式的实践与解析
一、核心概念1.1 定义策略模式(Strategy Pattern)核心思想是将算法家族封装起来,使它们之间可以相互替换,且算法的变化不会影响使用算法的客户端。该模式通过面向对象的多态机制,实现了算法与使用环境的解耦,让代码结构更清晰、可维护性更强。 1.2 核心解决的问题在传统开发中,若一个功能存在多种实现算法(如排序算法、支付方式、日志记录方式),通常会使用if-else或switch语句进行分支判断,选择不同的算法实现。这种方式存在以下问题: 代码耦合度高:算法逻辑与调用逻辑混杂在同一代码块中 扩展性差:新增算法需修改原有判断逻辑,违反开闭原则 维护成本高:算法逻辑分散,后续修改易引发连锁反应 可读性差:大量分支判断导致代码逻辑复杂,难以理解 策略模式通过将不同算法封装为独立的策略类,彻底解决了上述问题,使代码结构更符合面向对象设计原则。 二、结构组成策略模式包含三个核心角色,各角色职责明确,协同工作实现算法的灵活切换: 2.1...
C++ 装饰模式
一、模式定义与核心思想装饰模式(Decorator Pattern)是结构型设计模式的重要成员,核心思想是:通过组合而非继承的方式,动态为对象添加额外职责。它避免了继承体系的臃肿,允许灵活组合多个功能,实现 “即插即用” 的扩展效果。 关键特征: 装饰器与被装饰对象遵循同一接口(或继承同一基类) 装饰器持有被装饰对象的引用,实现功能叠加 支持多层装饰,形成职责链 二、UML 类图结构1234567891011121314151617181920+----------------+| 抽象组件(Component) |+----------------+| + operation() |+----------------+ ↑ |+----------------+ +----------------+| 具体组件(Concrete) | | 装饰器基类(Decorator) |+----------------+ +----------------+| + operation() | |...
C++ 工厂方法模式
一、模式简介工厂方法模式(Factory Method Pattern)是创建型设计模式的核心成员,其核心思想是:定义一个创建对象的接口(抽象工厂),但由子类(具体工厂)决定实例化哪个类(具体产品)。通过这种设计,将对象的创建逻辑与使用逻辑彻底分离,让代码更具扩展性和可维护性。 二、核心概念与结构工厂方法模式包含 4 个关键角色,形成清晰的继承体系: 抽象产品(Abstract Product) 定义产品的通用接口,所有具体产品都需实现该接口。例如 “交通工具” 抽象类,包含 “行驶” 纯虚函数。 具体产品(Concrete Product) 抽象产品的实现类,是工厂方法最终创建的对象。例如 “汽车”“自行车” 类,分别实现 “行驶” 方法。 抽象工厂(Abstract Factory) 定义创建产品的接口(工厂方法),返回抽象产品类型。例如 “交通工具工厂” 抽象类,包含 “创建交通工具” 纯虚函数。 具体工厂(Concrete Factory) 抽象工厂的实现类,重写工厂方法,返回具体产品实例。例如 “汽车工厂” 创建汽车对象,“自行车工厂”...
C++ 实现简单工厂模式
一、简单工厂简单工厂模式的核心是通过一个工厂类统一创建不同产品实例,本质是将对象创建逻辑与使用逻辑分离。C++ 作为面向对象编程语言,天然支持类与继承、多态、虚函数等特性,相比 C 语言的模拟实现,能更直接、优雅地满足简单工厂模式的设计意图,且无需手动管理函数指针与内存分配的绑定关系。 从两个维度理解适配性: 语法维度:通过抽象基类定义产品接口,具体产品类继承基类并实现纯虚函数,工厂类通过静态成员函数创建产品实例,完全符合面向对象的设计规范 功能维度:利用 C++ 的多态特性,调用者可通过基类指针 / 引用统一操作不同产品,无需关注具体产品类型;通过构造函数与析构函数自动管理内存,避免内存泄漏风险 二、核心结构2.1...
规范化 Git 提交 -- commitlint + husky
导言在团队开发或开源项目协作中,Git 提交信息如同代码的 “说明书”,直接影响代码可维护性与问题追溯效率。然而实际开发中,提交信息往往存在格式混乱、描述模糊等问题,例如 “fix bug”“update code” 这类无意义的表述。本文将通过 commitlint(提交信息验证工具)与 husky(Git 钩子管理工具)的组合,带你实现提交信息规范化与自动化校验,彻底解决这一痛点。 一、提交信息的常见问题与规范需求1.1 典型问题分析在未实施规范的项目中,提交信息通常存在以下问题: 格式混乱:无固定结构,有的包含类型,有的仅描述内容 描述模糊:如 “修改样式”“优化代码”,无法快速理解变更目的 信息不全:未关联需求编号或 Bug ID,问题追溯困难 语义缺失:无法通过提交信息判断变更类型(如功能新增、Bug 修复、文档更新) 1.2 规范标准选择:Conventional Commits目前行业广泛采用的 Conventional Commits(约定式提交) 标准,定义了结构化的提交信息格式: 12345<type>[optional...
团队 Git 协作规范整理
一、分支管理:搭建 “分工明确” 的协作骨架混乱的分支体系是团队 Git 协作的万恶之源。想象一下:有人在main分支直接写代码,有人用 “test1”“newcode” 命名分支,合并时根本分不清分支用途 —— 这种场景下,冲突和版本混乱只是时间问题。 1. 推荐:简化版 Git Flow 分支结构企业级项目中,无需过度复杂的分支模型,一套 “主分支 + 辅助分支” 的简化结构足以满足需求,核心是明确每个分支的 “生命周期” 和 “职责边界”: 分支类型 命名规范 核心用途 操作红线 主分支 main/trunk 存放生产环境代码,始终保持 “可部署” 状态(任何时候拉取都能正常运行) 严禁直接push,仅通过 PR 合并,合并前必须经过测试 开发分支 develop 团队日常开发集成分支,汇总各功能分支代码,是预发布前的 “代码蓄水池” 不直接在该分支写代码,仅接受功能分支合并 功能分支 feature/模块名-需求描述 单个功能 /...
Leetcode 0077. Combinations
77. CombinationsGiven two integers n and k, return all possible combinations of k numbers chosen from the range [1, n]. You may return the answer in any order. Example 1: 1234Input: n = 4, k = 2Output: [[1,2],[1,3],[1,4],[2,3],[2,4],[3,4]]Explanation: There are 4 choose 2 = 6 total combinations.Note that combinations are unordered, i.e., [1,2] and [2,1] are considered to be the same combination. Example 2: 123Input: n = 1, k = 1Output: [[1]]Explanation: There is 1 choose 1 = 1 total...

