#include 在 main() 函数中
我想知道是否有可能在 C 的 main() 函数中包含一些内容。
例如，在 Cell 程序中，我定义了 cache-api.h 的参数，稍后我想在 main() 函数中更改该参数。
我知道用 #define 定义的内容可以在程序中的任何地方用 #undef 取消定义，但是在重新定义所需的参数后，我必须再次包含cache-api.h 。这可能吗？
我怎样才能更优雅地解决这个问题？假设我想使用 cache_rd(...) 从主存储读取数据，但在 SPU 执行期间类型会有所不同，我如何同时使用 #define CACHED_TYPE struct x 和 #define CACHED_TYPE struct y 在同一个程序中？
预先感谢您的回答，我希望我的表达清楚。
I would like to know if it's possible that inside the main() function from C to include something.
For instance, in a Cell program i define the parameters for cache-api.h that later in the main() function i want to change .
I understood that what was defined with #define can be undefined with #undef anywhere in the program, but after redefining my needed parameters I have to include cache-api.h again . Is that possible?
How can I solve this problem more elegant ? Supposing I want to read from the main storage with cache_rd(...) but the types would differ during the execution of a SPU, how can i use both #define CACHED_TYPE struct x and #define CACHED_TYPE struct y in the same program?
Thanks in advance for the answer, i hope i am clear in expression.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
#define和#include只是在编译的“预处理”阶段发生的文本操作，从技术上讲，这是一个可选阶段。因此，您可以以各种方式混合和匹配它们，只要您的预处理器语法正确，它就可以工作。但是，如果您确实使用
#undef重新定义宏，您的代码将很难遵循，因为相同的文本在代码中的不同位置可能具有不同的含义。对于自定义类型，尽可能首选
typedef，因为您仍然可以从编译器的类型检查机制中受益，而且它不太容易出错，因为它比#define出现的可能性要小得多。 code> 宏会对周围的代码产生意想不到的副作用。#defineand#includeare just textual operations that take place during the 'preprocessing' phase of compilation, which is technically an optional phase. So you can mix and match them in all sorts of ways and as long as your preprocessor syntax is correct it will work.However if you do redefine macros with
#undefyour code will be hard to follow because the same text could have different meanings in different places in the code.For custom types
typedefis much preferred where possible because you can still benefit from the type checking mechanism of the compiler and it is less error-prone because it is much less likely than#definemacros to have unexpected side-effects on surrounding code.是的，这很好（可能不是最清晰的设计决策），但是 #include 就像将该文件复制并粘贴到 #include 所在的代码中。
Yes, that's fine (may not be the clearest design decision) but a #include is just like a copy-and-paste of that file into the code right where the #include is.
#define和#include是预处理器宏： http://en.wikipedia.org/wiki/C_preprocessor它们在编译之前被转换/内联。
回答你的问题……不，你真的不想这样做，至少是为了下一个必须尝试整理混乱的人。
#defineand#includeare pre-processor macros: http://en.wikipedia.org/wiki/C_preprocessorThey are converted / inlined before compilation.
To answer your question ... no, you really wouldn't want do do that, at least for the sake of the next guy that has to try and unscramble that mess.
您可以在任何文件中
#include任何文件。那么是否有效取决于文件的内容；特别是如果直接以文本形式输入该内容是否有效。头文件通常包含通常仅在函数定义之外（或任何类型的编码构造之外）有效的声明和构造 - 线索就在名称 header 文件中。否则，您可能会更改声明的范围，或更可能使编译单元在语法上无效。
专门为此目的编写的包含文件可能没问题，但不仅仅是任意的头文件。
通用头文件应该具有包含保护以防止多重声明，因此除非您取消定义保护宏，否则重新包含头文件在任何情况下都不会产生任何效果。
解决您的问题的一种可能的解决方案是创建单独编译的模块（编译单元），其中包含您需要调用的 API 的包装函数。在定义适当的配置宏后，每个编译单元都可以包含 API 头文件。然后，您将拥有这些包装函数提供的两个单独且独立的接口。
You can
#includeany file in any file. Whether it is then valid depends on the content of the file; specifically whether that content would be valid if it were entered directly as text.Header files generally contain declarations and constructs that are normally only valid outside of a function definition (or outside any kind of encoding construct) - the clue is in the name header file. Otherwise you may change the scope of the declarations, or more likley render the compilation unit syntactically invalid.
An include file written specially for the purpose may be fine, but not just any arbitrary header file.
General purpose header files should have include guards to prevent multiple declaration, so unless you undefine the guard macro, re-including a header file will have no effect in any case.
One possible solution to your problem is to create separately compiled modules (compilation units) containing wrapper functions to the API you need to call. Each compilation unit can then include the API header file after defining the appropriate configuration macros. You will then have two separate and independent interfaces provided by these wrapper functions.