PreProcessor Commands – Talk
Jump to navigation
Jump to search
mNo edit summary |
No edit summary |
||
Line 82: | Line 82: | ||
#include <mymod\inc\res.hpp> // include from the MYMOD mod directory | #include <mymod\inc\res.hpp> // include from the MYMOD mod directory | ||
// the file RES.HPP in the INC-directory | // the file RES.HPP in the INC-directory | ||
Is this the place to ask.... | |||
is there a __ARMA__ or __ARMA2__ | |||
If there isn't they would be "darn useful". | |||
~~barmyarmy |
Revision as of 20:02, 25 July 2009
Isn't this where we mention __EVAL and __EXEC? --Doolittle 18:40, 23 August 2007 (CEST)
- No. __EVAL and __EXEC are not done by preprocessor, they are evaluated by config parser. Preprocessor is not limited to config files, it is used for scripts as well. However, you have a point that those two should be documented somewhere.--Suma 21:18, 7 January 2008 (CET)
I'd say this very useful information should be found in the BIKI too.
Kudos to vektorboson! --PROPER Q 16:21, 5 January 2008 (CET)
MACROS There are basically three types of macros: Valueless macros, simple macros, macros with arguments. Valueless macros are of the form: #define MACRONAME If MACRONAME is found in the file, it is replaced by "nothing"; those macros are rather used for conditional macros like #ifdef and #ifndef. Simple Macro: #define MACRONAME value If MACRONAME is found in the file, it is replaced by value. Macros with arguments: #define MACRONAME(x, y, z) x loves y, but not z. If a parameter name is found in the value text, then it is replaced by the corresponding parameter. #define VALUE(x) x ammo = VALUE(10); // expands to: ammo = 10; But there is also stringification and concatenation: #define STRING(x) displayName = #x; STRING(M1A1) // expands to: displayName = "M1A1"; #define PROXY(x) class Proxy##x { model = #x; }; PROXY(ak47) // expands to: class Proxyak47 { model = "ak47"; }; PREDEFINED MACROS CfgCheck predefines right now exactly one macro: __CFGCHECK__ - that is two underlines followed by CFGCHECK (case sensitive!) followed by two underlines. You can use this to hide sections from OFP, or vice versa (use #ifdef and #ifndef). This can be useful when using #include, as CfgCheck interprets #include in a special manner. One example is, you are using #include to separate parts of the config into different files. When running CfgCheck on the config.cpp, you'll get probably an error (file not found) or you will be scanning the included files in the PBO in your addons-directory instead of the local file. Here you use the following workaround: #ifdef __CFGCHECK__ // this is for CfgCheck #include "weapons.hpp" #include "ammo.hpp" #include "vehicles.hpp" #else // this is for OFP #include <myaddon\weapons.hpp> #include <myaddon\ammo.hpp> #include <myaddon\vehicles.hpp> #endif FILE INCLUSION (INCLUDES) File inclusion is done with #include; there are two types of includes: #include "path" // relative inclusion #include <path> // system inclusion I don't think OFP makes a difference between the two, but I think it is better to make a difference. You'll see the former in the commented config. So if you're writing a Mod config, then use the former; if you want to include from somewhere of the OFP directory or from a PBO, then use the latter. #include "CfgMoves.hpp" // includes CfgMoves.hpp from the same directory // as the "current" file #include <myaddon\res.hpp> // include from MYADDON.pbo file res.hpp #include <mymod\inc\res.hpp> // include from the MYMOD mod directory // the file RES.HPP in the INC-directory
Is this the place to ask....
is there a __ARMA__ or __ARMA2__
If there isn't they would be "darn useful".
~~barmyarmy