c++全局常量问题
我们在一系列文件中定义了这些“实用”常量集。问题源于这样一个事实:太多文件包含这些全局常量文件,如果我们向其中一个文件添加常量并尝试构建,它会构建整个库,这需要一个多小时的时间。
有人能为这种方法提出更好的方法吗?我们将不胜感激。
We have these set of "utility" constants defined in a series of file. The problem arises from the fact that TOO MANY files include these global constant files, that, if we add a constant to one of those files and try to build, it builds the whole entire library, which takes up more than an hour.
Could anyone suggest a better way for this approach? That would be greatly appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
首先,如果您直接在标头中定义它们,我建议将它们声明为 extern const,然后在 cpp 文件中定义它们:
这样,至少可以在不重建的情况下更改定义。
其次,检查它们被包含在哪里。如果常量文件包含在低级标头中,是否可以将包含内容移动到 cpp 中?删除它可能会降低耦合,因此不必重建太多。
第三,分解该文件。我建议映射出您最终想要的结构,开始向新结构而不是旧文件添加新常量。最终(当您确定已经获得所需的结构时),将旧文件重构为新结构,并使旧文件包含整个结构。最后,检查并删除旧文件的所有包含内容,将它们指向适当的新部分。这会破坏重构,因此您不必一次完成所有工作。
第四,如果头文件发生更改,您可能可以欺骗编译器不进行重建。您必须检查编译器的文档,这可能不安全,因此您偶尔也想添加完整的构建。
First, if you are defining them directly in the header, I'd suggest instead delcaring them extern const, and then defining them in a cpp file:
That way, at least definitions can be changed without a rebuild.
Second, examine where they are being included. If the constant file is being included in a low level header, can the include be moved to the cpp instead? Removing it might lower the coupling so it doesn't have to rebuild as much.
Third, break up that file. I'd suggest mapping out a structure you'd eventually want, start adding new constants to the new structure instead of the old file. Eventually (when you are sure you've got the structure you want), refactor the old file into the new structure, and make the old file include the entire structure. Finally, go through and remove all includes of the old file, pointing them at the appropriate new sections. That'll break up the refactoring so you don't have to do it all at once.
And fourth, you might be able to trick your compiler into not rebuilding if the header file changes. You'd have to check your compiler's documentation, and it might be unsafe, so you'd occasionally want to add full builds as well.
您真的需要将每个全局定义都包含在每个文件中吗?您可能应该将常量分成几类,然后将它们分成不同的文件。
包含的每个 .h 都会简单地复制到包含它的文件中。如果您更改文件中的某些内容(直接或通过更改包含的内容),那么它绝对需要重新编译。
另一个解决方案是拥有一个 .h 文件,该文件具有字符串名称/值映射的访问器。然后,您可以在该映射/访问器的 .cpp 文件中插入新值。您输入的每个新值只需要重新编译 1 个文件。
另一个解决方案是不在任何地方包含头文件。只需 extern 每个 .cpp 文件中所需的变量即可。
Do you really need every global define to be included in every file? You should probably split the constants up into categories and then split them into different files.
Every .h that is included is simply copied at that point in the file that is including it. If you change something in a file (either directly or via changing something that is included) then it absolutely needs to be recompile.
Another solution would be to have a .h file that has an accessor to a map of string name/values. Then in the .cpp file of that map/accessor you can insert the new values. Every new value you put would only need 1 file to be recompiled.
Another solution is not to include the header file anywhere. Simply extern in the variables you need in each .cpp file.
也许是时候进行一些重构来提高凝聚力并减少软件设计中的耦合。拆分全局常量文件将使模块能够更有选择性地选择需要包含哪些常量,这将消除一些
不必要的耦合。在极端情况下,您可以将其一直分解为每个文件一个常量,并确保每个模块仅包含它需要使用的常量。
但这可能会导致内聚性较差,因为常量可能自然地落入相关组,因此需要一个常量的模块通常也会
需要该组中的许多其他人。因此,诀窍是在各个全局文件中找到更好的常量分组,然后确保每个模块仅包含其需要的内容。
Perhaps it's time to do some refactoring to improve the cohesion and reduce the coupling in your software design. Splitting the global constant files would allow modules to be more selective about which constants need to be included, which will eliminate some of the
unnecessary coupling. In the extreme case, you could break it all the way down to one constant per file, and ensure that each module only includes the constants it needs to use.
But that could result in poor cohesion, in the sense that the constants might naturally fall into related groups, such that a module that requires one constant will generally also
require many others from that group. So the trick is to find a better grouping of constants in the various global files, then ensure that each module only includes what it needs.
(编辑:我没有想到外部常量。确实,我的想法有点愚蠢。)
(编辑:我的“愚蠢”宏想法实际上节省了添加常量时的构建时间。感谢您指出这一点,Brian!
)并行构建:-)
说真的,我认为一个解决方案是创建另一个名为 utility_ex.hpp 的标头,或者添加偶尔合并到 utility.hpp 中的新常量(或任何当前实用程序常量标头的名称)。
另一个(效率较低)的解决方案是使用这样的宏:
现在假设您希望将 MAX_CUSTOMERS 定义为 100。您可以
在代码中说:。在 get_constant 的代码中,您可能有:
(Edit: I didn't think of external constants. Indeed, my idea is kinda stupid.)
(Edit: My "stupid" macro idea actually saves build time for when constants are added. Thanks for pointing that out, Brian!)
Use parallel building :-)
Seriously, I think one solution would be to create another header called utility_ex.hpp or something where you add new constants that you occasionally merge into utility.hpp (or whatever your current utility constants header is called).
Another (less efficient) solution would be to have a macro like this:
Now suppose you want MAX_CUSTOMERS to be defined as 100. You can say:
in the code. In get_constant's code, you might have: