353c553721258749e62cb0935b141f445e7912e4
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DeepSeek V4.1 Flash
|
34365b3c1c |
perf(size): 用自写整数格式化替换全部 std::to_wstring / std::to_string
背景：Code Review 报告 §10.3 / §11.5 建议「替换 std::to_wstring / std::to_string，
可去掉 gdtoa 链（≈33 KB）」。本轮把它做完，并给出这条建议的**真实边界**。
一、新增 `Utf8Util::FormatInteger*`（手写十进制展开，不经 printf）
* `FormatInteger(long long)` / `FormatIntegerUnsigned(unsigned long long)` /
`FormatIntegerNarrow(long long)`（后者供 MatLoader 拼 HDF5 成员路径）。
* 语义与 `std::to_wstring` / `std::to_string` 完全一致：`0` → `"0"`、负数带 `-`、
`LLONG_MIN` 用模 2^64 语义取绝对值（不会溢出）。
* 这样做的直接理由：预编译 libstdc++ 的 `to_string` 内部转调 `__mingw_swprintf`，
工程里只要留一处，MinGW 的 printf 引擎（`mingw_wpformat.o`）+ gdtoa 就必然被链入。
二、全仓替换（76 处 `to_wstring` + 2 处 `to_string`，20 个文件）
* `MatLoader.cpp` 的 `TrimNumber` 整数分支也改为 `FormatInteger`（它曾是产物里
**最后一个**引用 MinGW printf 的调用点）。
* 需要的地方补 `#include "Utf8Util.hpp"`（仅 `MatLoader.cpp` 一个新 include，其余由
`PlotViewInternal` / `SignalPanelInternal` / `ApplicationInternal` / `DataModelInternal`
已经包含）。
三、⚠️ 实测结论：gdtoa **去不掉**（把这件事彻底查清并写进 Makefile 注释）
* 只替换 `to_wstring`/`to_string`：**−1,024 B**（787,968 → 786,944）。
* 再叠加 `-D__USE_MINGW_ANSI_STDIO=0`（把 `swprintf` 让给系统 UCRT）：**0 字节**。
* 根因（定位到文件与行）：libstdc++ 的
`lib/gcc/.../include/c++/x86_64-w64-mingw32/bits/os_defines.h:48-51` **无条件**执行
`#undef __USE_MINGW_ANSI_STDIO` + `#define __USE_MINGW_ANSI_STDIO 1`
（注释：libstdc++ depends on POSIX-definitions of those functions）。
`g++ -E -dM` 实测最终值恒为 1 ⇒ **任何 C++ TU 的 `swprintf` / `strtod` 都是 MinGW 版本**，
命令行无法覆盖。
* 要真省这 33 KB 只能自己实现「浮点 → 十进制（正确舍入）」与「浮点解析的
十六进制/inf/nan 分支」，等价于重写 gdtoa。**判定：不做**（风险 >> 收益）。
* 该开关已回退，Makefile 里保留一段说明，避免后续接手者重复这两次实验。
四、验证
* 新增单元测试 `integer_replacement_matches_std`：12 个有符号样本（含 LLONG_MIN/MAX）
+ 5 个无符号样本（含 ULLONG_MAX），与 `std::to_wstring` **逐字符对照**，
并校验窄/宽版本内容一致。
* `UnitTests`：`checks=260 failed=0 cases=19`（新增 41 条断言）。
* `OffscreenChecks -all`：6 个检查全 PASS，`checks=87 failed=0`。
* `panels -mode compare`：7 个面板像素哈希与几何**逐项不变**
（整数文本从 `to_wstring` 换到手写实现后，渲染结果零差异 —— 这是最强的语义证据）。
* release 全量零 error / 零 warning；产物 787,968 → **786,944 B**。
|
||
|
DeepSeek V4.1 Flash
|
ea704b03ea |
fix(plotview): 边沿计数表格归位、统计面板悬停时持续更新、加载不再被统计阻塞、统计提速
1) 表格改造归位（上一轮误做在中心轴上） - 「边沿计数」改为表格：表头（信号名/上升沿计数/下降沿计数）、每信号一行、 行底色取信号配色、三列对齐、内容可滚动（Lane::edgeCountScroll）。 - 「中心轴边沿计数」恢复为可滚动分组列表（条目栏 + 复选框 + 展开后统计行 + 两行滑块）， Lane::EnsureEdgeCenterItem 恢复默认展开。 - EdgePanelWidth / EdgePanelLayoutFor / PaintEdgeCursor 统一 listStyle / countTable 判定； EdgeCenterTableHeader 更名为 EdgeCountTableHeader。 2) 鼠标持续移动时统计面板不更新 - 根因：交互态（拖拽或 140ms 内移动）把统计数字整段从面板缓存键中跳过， 只要鼠标不停移动就永远命中旧缓存。 - 修法：扫描推进/完成时自增 m_edgeScanRevision，Paint 开头转为 m_panelStatsVersion （非交互帧立即同步，交互帧按 kEdgeScanStatsRefreshFrames=4 节流）， PanelSlotKey 对 COUNT/CENTER 仅混入该版本号（O(1)，不再逐信号查询）。 3) 统计进行中无法加载文件 - 新增 PlotView::SetLoadingBusy：加载期间统计时间预算归零、跳过浮动面板绘制、 不再自请求扫描帧；Application::LoadFileAsync 进出各设置一次。实测加载 22~31ms。 4) 统计提速 - 扫描预算由固定采样对改为 QPC 时间片（非交互 6ms / 交互 1.5ms，每块检查超时）， 采样对配额改为按未完成状态数公平分摊并把上限提到 8M（交互 2M）。 - 真实 MF4-Record.MF4（283 信号）全部统计状态在 1 帧内完成；悬停+移动帧中位 2~3ms。 验证：离屏探针 p20/p20c/p20d/p21/p22/p23/p25 全绿（新增 p25 12 项）； make release / make debug 零 warning；Release 808,960 B。共享规则已同步到 Documents/agent_mem.md。 |
||
|
DeepSeek-V4.1-Flash
|
5b24dacee0 |
悬停高亮恢复旧版外延观感 + 支持 MATLAB .mat（v7.3 / HDF5，嵌套分组）
一、悬停高亮「几乎看不到、只是曲线换了颜色」（对比提交 |
||
|
DeepSeek V4.1 Flash
|
e6b7bf66ec |
按组件目录结构把四个巨型实现文件拆分为多个协作文件（PlotView / SignalPanel / Application / DataModel）
承接上一条提交（0871eb0）—— 该提交只完成了 Components/Shared 与注释/命名清理，并**主动未做**
大文件拆分；本提交把大文件拆分补齐，至此“按功能拆分逻辑块到各组件自己的 Inc/Src”已落地。
## 一、拆分结果
| 原文件 | 拆分后 |
| --- | --- |
| Components/PlotView/Src/PlotView.cpp（13 695 行 / 544 KB） | PlotView.cpp(787) + PlotViewPaint.cpp(6 367) + PlotViewInteraction.cpp(2 715) + PlotViewFeatures.cpp(3 005) + PlotViewInternal.hpp(936) |
| Components/SignalPanel/Src/SignalPanel.cpp（4 184 行） | SignalPanel.cpp(1 141) + SignalPanelPaint.cpp(697) + SignalPanelInteraction.cpp(2 095) + SignalPanelInternal.hpp |
| Components/Application/Src/Application.cpp（3 135 行） | Application.cpp(1 427) + ApplicationCommands.cpp(1 184) + ApplicationLoading.cpp(270) + ApplicationInternal.hpp |
| Utilities/Src/DataModel.cpp（2 615 行） | DataModel.cpp(1 583，含自由函数区) + DataModelTab.cpp(732) + DataModelInternal.hpp |
分片职责（以 PlotView 为例）：
core 视图核心：构造/析构、上下文、布局、坐标映射、视界与平移、网格结构与归属
paint 渲染与像素缓存：全部绘制、场景/装饰缓存、每网格图层、宽基底与滚动补条
interaction 交互与编辑：命中测试、鼠标/键盘、光标形状、内联输入框、浮动面板层序
features 视图特性与派生数据：光标读数/提示/缩放、自适应、吸附、单点、派生曲线线程池、
边沿统计、实验性功能参数
（SignalPanel 为 core/paint/interaction；Application 为 core/commands/loading；
DataModel 为 core/tab。）
## 二、关键手法（这是能安全拆开的前提）
原文件的辅助区都是**匿名命名空间**（PlotView 约 870 行常量与工具函数），被所有成员函数广泛引用。
直接拆文件会让各 .cpp 拿不到这些工具，因此：
1. 把该块整块搬进 `<组件>Internal.hpp`，从 `namespace { }` 改为**具名**命名空间
（pvdetail / spdetail / appdetail / dmdetail）；
2. 块内**每个函数与常量都标 inline** ⇒ 多个翻译单元共用同一个定义：既不重复符号，
也不产生 N 份函数定义；
3. 头部末尾 `using namespace <ns>;` ⇒ 各 .cpp 函数体里原有的非限定调用（IntersectRect /
NiceStep / ClampDouble …）**一行都不用改**；
4. 成员定义按「方法名 → 分片」归类后**整块搬移** —— 全程**纯代码搬移**，没有改动任何一行函数体。
## 三、拆分过程中踩到并修正的四个坑（已固化到 .preflight/perf/split_component.ps1）
1. `[[maybe_unused]]` 等属性**必须排在 inline 之前**（`inline [[x]] T` 非法）；
单独的 `{`/`}` 行、注释行、`struct`/`enum`/`using`/`template` 行不能加 inline。
2. 匿名命名空间的**结束行可能带注释**（`} // namespace`），只认 `^\t}$` 会一路匹配到后面
某个成员函数的结束括号，把大段成员定义误当成“辅助区”搬走。
3. **首个成员定义之前的所有行**必须跟着进核心文件：DataModel.cpp 在匿名命名空间之后、
首个成员定义之前还有约 390 行命名空间外的自由函数（SignalStats / ComputeStats /
CacheSparseSamples / ApplySinglePointDefaultStyle …），漏掉会被静默丢弃。
4. 内部头必须带上原文件真正用到的全部头：DataModel 需要 Theme.hpp / <cstring> / <cstdio> /
<deque> / <atomic> / <cwctype> / <new>（原文件靠这些头才编译得过）。
## 四、附带完成的命名审计
PlotView 中残留的 File 语义命名一并修正：LaneSpansMultipleFiles → LaneSpansMultipleGroups、
firstFile → firstGroup、multiFile → multiGroup、SceneCacheKey::haloFile → haloGroup。
## 五、验证（全部离屏：SW_HIDE + 不注入真实输入 + 进程/线程 BELOW_NORMAL）
- .preflight/perf/verify.exe（PlotView 渲染/交互，含逐像素断言）49/49
- .preflight/perf/panelanim.exe（信号面板：卷尺式折起/展开、筛选态、悬浮组名、目标行）156/156
- .preflight/perf/datacheck.exe（数据层：单轴/多时间轴 CSV、MF4、重命名语义）69/69
- .preflight/perf/edgecheck.exe（边沿统计与面板排版）46/46
- make release / make debug 零警告。
即：拆分后**行为与拆分前完全一致**（纯代码搬移，四套探针全绿）。
## 六、体积（诚实记录）
Target.exe: 754 176 → 764 416 B（+10 240 B，+1.4%）
因为 inline 工具函数会在每个引用它的翻译单元里各生成一份（PE/COFF 链接器没有 ICF 合并）。
这再次印证：拆分解决的是**可维护性**，不是体积（本轮的 −24.6% 全部来自 ICO 256×256 条目改 PNG）。
## 七、文档
Documents/agent_mem.md：§9.37 新增“七、多文件拆分（已完成）”与“八、仍未完成”（只剩
Lane → LanePanelState、模态提示解耦、MF4 压缩块三项）；§11.2 新增第 91、92 条（多文件化的
唯一安全手法 + 体积代价）。Documents/refactor_report_2026-10-16.md 同步更新 §五/§七/§八。
|