heavy use of #include and #define problems?

[sakura_chan 9]

I am wondering if there is any drawback to heavy usage of the # commands in a config.cpp. An example would be only a few actual #include and #define commands but have them called several thousand times. I guess what I want is a better understanding of how the config is compiled at Arma startup and also binerization's effect on the command. When you binerize it, does it merge them all into one file or does it still keep the separate .hpp files? I'm working with a lot of classes and files I'm trying to keep it as simple as possible, making generic config files that are later filled in by simple included defines.

[mikero 79]

Your need, and method of approach is 100% the 'right' way, Bottom line is, if you are going to use A #include then bloody well start using a heap of them.

To answer your question: *after* binarisation, there is only one, single bin file. All the included files play no part at all in game and should not be included the pbo. The binary file has merged everything into one single mongrel. Should you later, decide to debanarise (eg DeRapify), you get one, single, large, config.cpp

There is no downside to using a binarised config that had (past tense) one squillion includes.

One enormous caveat to this is that mission.sqm's and their desc.ext's also have no issue with #includes, but some balance is required since desc.ext can never ever be binarised.

To answer your question further, #defines operate in *exactly* the same manner. Their inclusion can produce enormous quantities of text, but it is all binarised out. The text (of course) remains quite large (in now binarised form) but the processing required to create that text no longer exists, hence zero lag.

Edited September 28, 2012 by Mikero

[sakura_chan 9]

Perfect thats what I was hoping for! This is gonna save me a lot of headaches.

[Deadfast 43]

some balance is required since desc.ext can never ever be binarised.

Just a quick question, why?