Talk:PreProcessor Commands

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

Would be nice if #define in one file (like init.sqf) will register it globally --Doolittle 06:32, 26 August 2009 (CEST)

@Doolittle, Your probably right, it would be. Can you give an example in the context of preprocessor directives and config's that you see a global #define being of benefit?

If you utilize the #include method I described in the article you can get your #define's to be available for each of your addon config's when they are parsed into binarized form AND you can set it up so you only have singlular version's of these include files. Keep's everything clean, robust and manageable. -- Sy 04:07, 2 September 2009 (CEST)

Preprocessor errors

When I got a CTD where all I really had was "Preprocessor failed on file X - error 6.", I was left without much of a clue what was wrong - inspecting the file didn't show much when I didn't know what I was looking for. Luckily, after a number of google search attempts, I found a link to the source of the problem. Since the solution (or rather, only hint) was only available in google cache (the page had since shut down) I made sure to document it at PreProcessor Errors.

Try rapify or squint. Both will show you errors of this type.--Kju 07:27, 6 September 2010 (CEST)

_FILE_

The returned string is relative to the command line it is invoked on.

While it would be exceptionally useful to use it as a substitute for the pboprefix eg

model=__FILE__\thingo.p3d;

binarise \my\project\config.cpp

the returned string contains the DRIVE:

p:\my\project\thing\config.cpp

it would be really nice if we had some way of getting at the path only. 02script allows this

[this%0] StripPath @ 1;

binarise/engine does not.