PreProcessor Commands – Talk

From Bohemia Interactive Community
Jump to navigation Jump to search

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.


#include

@STR, You say #include allows for relative & absolute path includes. Which version of the tools are you using because from memory binarize.exe from 'BI_Editing_Tools_2_Setup.exe' and 'BI_Editing_Tools_2_5_1_Setup.exe' doesn't allow this? -- Sy 21:55, 31 October 2011 (CET)


I modified #include info based on PDF file http://ofp-faguss.com/files/ofp_preprocessor_explained.pdf

Relative (#include "codestrip.hpp") and absolute addon (#include "<addon folder name>\<file>") paths should work, I'm not completely sure about going one folder up (#include "..\codestrip.txt") and disk path (#include "d:\temp\codestrip.txt).

Feel free to correct it, but please try to keep info simple, avoiding unnecessary wall of text which was there previously ;)

++Str 08:55, 1 November 2011 (CET)

There's still, in my view, an unnecessary 'wall of text' there. #include accepts relative or \hard addressing, including binarise.exe in the tools above AND, the engine. As STR says, they are relative to the file they are encountered in, or, \PboPrefix. For the engine, they are a popular method of 'getting at' a common library of components for both missions and addons. But use of drive:specifiers and ../back pathing is not recommended. Mikero (nee Ook?) 16:21, 1 November 2011 (CET)



23.10.11 edit

I've noticed that you've reshaped this article copying parts from the doc. Problem is that the doc refers ONLY to OFP and you make it look like it's for all games.
http://forums.bistudio.com/showpost.php?p=2025467&postcount=12
--Faguss 04:45, 13 November 2011 (CET)

Retrieved from "https://community.bistudio.com/wiki?title=Talk:PreProcessor_Commands&oldid=226687"