c++oding="utf-8" ?>
推荐用 std::regex_replace 配合精准正则模式匹配并剥离 git 附加段（如 -gabc123、-dirty），避免误删合法版本标识；编译期用 cmake 预处理更可靠高效。
用 std::regex_replace 去掉 Git 分支/提交哈希等版本标记
如果字符串里混着类似 myapp-v1.2.3-rc1-ga1b2c3d-dirty 这种带 Git 描述符的版本号，直接用 std::string::find + erase 很难覆盖所有变体（比如有无 -dirty、有无 -g 前缀哈希、哈希长度不固定）。正则最稳。
常见错误是写太宽泛的模式，比如 "-g[0-9a-f]{7,}" 会漏掉 -dirty，或误删路径中合法的 -g 字符串。推荐匹配整个“Git 附加段”：
-
std::regex pattern{R"(-[a-zA-Z0-9]+(?:-[a-zA-Z0-9]+)*-(?:g[0-9a-f]{7,}|dirty|pre|rc\d*))"};—— 覆盖-main-gdeadbeef、-develop-dirty、-v2.0.0-rc2 - 若只要剥离 Git 元信息（保留主版本如
v1.2.3），用std::regex_replace(s, pattern, "")即可 - 注意：C++11 的
std::regex在某些旧 libstdc++（如 GCC 4.8）上对 Unicode 或复杂回溯支持弱，测试时优先用 GCC 5.3+ 或 Clang 3.7+
手动扫描时避开 std::string::erase 的迭代器失效陷阱
有人想用循环 find 找到所有 -g 开头的子串再删，但边遍历边 erase 容易越界或跳过内容——因为 erase 后后续字符前移，而迭代器没重置。
安全做法是反向扫描或记录位置后批量删：
- 收集所有要删的起始索引和长度，按索引倒序排序，再逐个
erase（避免偏移错乱） - 或改用
std::string::substr拼接非目标段：比如已知版本格式为"{base}{sep}{git_part}"，可先find_last_of('-')判断是否含 Git 段，再截取前面部分 - 别依赖
std::string::replace(pos, len, "")时传入std::string::npos当len—— 它会崩，必须显式算长度
构建时预处理比运行时解析更可靠
真正的问题常不在 C++ 代码里怎么删，而在字符串从哪来。如果版本字符串来自 git describe 或 CMake 注入的宏（如 -DVERSION_STRING="v1.2.3-gdeadbeef"），在编译期就剥离更干净。
CMake 示例：
set(GIT_DESCRIBE ${GIT_DESCRIBE} CACHE STRING "git describe output")
string(REGEX REPLACE "-g[0-9a-f]+(-dirty)?" "" CLEAN_VERSION ${GIT_DESCRIBE})
add_definitions(-DVERSION_STRING="${CLEAN_VERSION}")
这样 C++ 侧拿到的就是纯版本号，不用 runtime 正则开销，也避开了跨平台正则引擎差异（Windows MSVC 的 std::regex 性能尤其差）。
注意语义边界：别把合法版本号当 Git 信息误删
像 v2.0.0-rc1 是正式发布候选版，不该被当成 Git 临时标记删掉；而 v2.0.0-rc1-gabcd123 才是带提交哈希的开发快照。区分关键在有没有 -g 或 -dirty。
所以模式不能只认 -rc 或 -pre，得结合上下文：
- 安全策略：只删以
-g、-dirty、-untracked结尾的后缀段 - 或者要求输入字符串严格遵循
MAJOR.MINOR.PATCH[-PRERELEASE][-gCOMMIT[-dirty]]格式，用std::regex捕获组提取主版本 - 若输入来源不可控（如用户传参），建议先做白名单校验再处理，否则
regex_replace可能静默破坏数据
最麻烦的是混合场景：一个字符串里既有路径又有版本号，比如 /opt/myapp-v1.2.3-gdeadbeef/bin/start —— 这时不能全局删 -g，得先分离路径组件，再对 basename 处理。没通用解法，得看你的数据契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
