PreProcessor Commands – Talk

From Bohemia Interactive Community
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