如何理解“ from xxx import * 这种写法会给你带来无穷无尽的噩梦？”?

事实上在写纯C的时候你会天天遇到这种噩梦。因为C语言头文件不仅没有模块来控制导出，而且没有命名空间来控制符号的使用范围。

最典型的遇到这个噩梦的场景就是Windows.h。只要你include了它，它就会往你的全局命名空间疯狂排泄：

• 一堆搞不明白为什么要大写的typedef。
• min和max，是宏。
• 一堆用宏实现的实用函数。用static inline不好吗？
• 用宏实现的A/W API控制。在有C++的情况下用重载不行吗？

而且Win32 API这坨答辩你必须整个一起吃。如果你单独include某个子级头文件，那么会出现各种奇怪的问题。

说真的，C++就应该重新用元数据造一个win32pp.hpp。这真的比直接用windows.h这坨答辩强多了。

这里继续幻想时间一下。可以尝试造一个类python的DSL，这种DSL由一系列import语句构成。然后写个程序，利用clang解析windows.h，根据import语句自动导出对应的符号到一个新的头文件，这个头文件会自动使用命名空间隔离。

想写。真的很想啊。可惜铸币军训。唉。

补充几点抬杠（大雾）论证一下这玩意有点必要性。以及我提到我这个幻想主要是为了防止铸币军训让我忘掉它。

1. 虽然wrl/cppwinrt有良好隔离，还能间接解决一部分windows特定的需求，但是它们都不是Win32 API的1:1映射，也就是说如果你就是撞上了要用某个Win32 API的场合它们也帮不了你。
2. wil只是微软仗着自己明白Windows.h的控制宏整出来的。它采用的是include子级文件的方式，只是没有用到不需要的头文件，而没有隔离掉所有不需要的符号。
3. 能使用纯C头文件是C++生命力的来源之一，但这也不失为一个诅咒。例如，其他语言由于不能使用Windows.h，大多自己从元数据造了一套binding，而这些binding都能与语言的模块机制配合，提供远超纯C的体验。所以我上述的“重造一个win32pp.hpp”并非没事找事，如果把现代C++看做一门全新的语言，再重新让它与纯C库建立联系，就能抛却纯C的一些缺陷。
4. 套模板生成动态加载器是好的方法，打算塞进去。
5. C++缺乏一种主动隔离和过滤符号的机制。控制性宏确实能选择是否引入某些符号，但是它们只能由库作者主动提供，使用者只能顺从。
6. 暂时只考虑纯C头文件。因为C++头文件大多已经选择了名字足够独特的命名空间来隔离。