在2的典型场景下，需要3，速度更快。

现状：只能完整编译（280个cpp）5min，希望：精准编译受影响的130个cpp，<5min。
【 在 ziqin 的大作中提到: 】
: 你现在的痛点是哪儿？
: 1. include梳理不清楚
: 2. 改了某个头文件不知道哪些需要重新compile和link?
: ...................
--
FROM 61.185.161.*

梳理是编译器的功能。cl.exe /showIncludes 输出的是绝对路径。对标gcc是 -MMD，链接2。你举的异常情况不会存在。

算了。感谢热心，看你对这问题没研究过，更说明我踩了个冷坑。

你那个make_closure，用上模板没？我翻了聊天记录，是你这个ID啊。
【 在 ziqin 的大作中提到: 】
: 1.  首先说你这个梳理是不是真的没有bug就很难说。""和<>的include，带相对路径和不带相对路径include，会不会是同目录里的private文件，这么多文件，有没有命名冲突。这些随便来一个，都不是随便对比名字就能搞定的
: 2. 全部编译一次才5分钟，也不算啥，你们要是一天到晚需要整个项目完整编译，那你得考虑考虑更大的问题了
: 所以没到万不得已，别整什么自动化编译。
: ...................
--
FROM 36.45.25.*

那必须的。
不过受限于开发平台，自定义类已经根据框架要求加了很多宏，定义工厂方法与接口等等，自己相关的operator。改成pimpl不现实。
另外除了Qt，还有哪个工程用这个的？太啰嗦了。私有实现类fmaily的继承，得与接口保持一致，我记得有继承的父子关系和业务上下级的父子关系搅在一起时，代码就不好写，另外还有Qptr DPtr的宏，是处理啥来着。
【 在 KnightZorro 的大作中提到: 】
: pimp方式能优化你的速度吗?
--
FROM 61.185.161.*