使用#include包含代码段

本文介绍了使用#include包含代码段的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在使用一个第三方开放源代码应用程序，该应用程序做了我认为很奇怪的事情.我想听听您对您是否认为这是错误的/邪恶的/可憎的/等等，或者是否有正当理由这样做的意见.

I'm using a 3rd party open-source application that does something I think is strange. I'd like to hear your opinion on whether you think this is wrong / evil / an abomination / etc., or if there is some justifiable reason to do this.

简而言之，他们使用#include pre-proc指令来包含包含代码片段的头文件".不是功能原型.没有内联功能.只是部分代码.

Simply put, they use #include pre-proc directives to include "header files" that include fragments of code. Not prototypes of functions. Not in-line functions. Just sections of code.

这是一个简单的例子.首先是main.cpp文件:

Here is a simple example. First the main.cpp file:

#include <iostream> //Other "normal" includes here... int main(int argc, char *argv[]) { cout << "Initializing program..." << endl; #include "parseArgs.h" // ... remainder of the program cout << "Exiting." << endl; return 0; }

在parseArgs.h头文件中，有一个小的代码片段.请注意，这仅是parseArgs.h文件中的内容.这不是功能的一部分.没有包含防护，只有以下4行:

And within the parseArgs.h header file, a small code fragment. Note that this is exactly and only what is in the parseArgs.h file. This is not part of a function. There are no include guards, just the following 4 lines:

argList args(argc, argv); if(!args.valid()) { cout << "Invalid arguments."; exit(1); }

在实际程序中，有#include指令中的几个指令，每个指令都执行另一项小任务.

In the real program, there are several of these #include directives, with each one doing another small task.

这似乎是危险和疯狂的.我不知道他们为什么不编写这些函数并将其称为函数.

It seems dangerous and crazy. I don't know why they don't write and call these as functions.

您的想法和意见?

推荐答案

我认为您在这里谈论的是 OpenFOAM .这些代码片段解决的问题是避免OpenFOAM中的许多应用程序需要重复样板代码.将此代码放在函数中并不能解决问题，因为在函数内部声明的变量在其作用域内是局部的.也许可以提出一种包含这些变量作为成员的基类方案.但这只会增加另一层间接寻址，并不能真正解决任何问题.您仍然依赖变量名(或者，如果要使其干净，请使用吸气剂名称).

I think you're talking about OpenFOAM here. The problem that these code snippets solve is that of avoiding the duplication of boilerplate code that many applications in OpenFOAM need. Putting this code in a function won't solve the problem, because the variables declared inside a function are local to its scope. One could perhaps come up with a scheme of base classes that contain these variables as members. But that would just add another layer of indirection that doesn't really solve anything. You're still dependent on variable names (or, if you want to make it clean, getter-names).

就个人而言，我不确定这种做法是好是坏.就是这样，它是OpenFOAM代码文化的一部分(如果需要，可以是 local lingo ).乍看之下，这很令人惊讶，但人们很快就习惯了.

Personally, I'm undecided on whether this practice is good or bad. It is how it is, and it is part of the OpenFOAM code culture (or local lingo, if you want). At first sight it's surprising, but one gets used to it pretty fast.

但是，除非您自己开发OpenFOAM应用程序/扩展，否则我强烈建议您不要这样做. OpenFOAM在某种程度上是独特的，因为它实际上包含数百个可执行文件，这些可执行文件都需要重叠的样板代码，否则这些代码将很难维护.如果您不在那种情况下，那就不要这样做.

However, unless you are developing OpenFOAM applications/extensions yourself, I would strongly discourage this practice. OpenFOAM is somewhat unique in that it contains virtually hundreds of executables that all require some overlapping boilerplate code that would be hard to maintain otherwise. If you're not in that situation, then don't do it.