mailto: blog -at- heyrick -dot- eu

The many levels of conditional compilation

I have a program that I am writing that contains a variety of debugging instructions to allow specific bits of debug/tracing code to be activated. One thing that all of the bits of code require is the debug() function to write the printf style string provided to DADebug.
In order to make this a little bit smarter, I wanted to simply choose which (if any) debug options I want, and the compiler itself can figure out whether or not the lower level debugging code should also be included.
This isn't difficult. The process is like this:
// Output information on THIS ?
#define DEBUG_THIS 1

// Output information on THAT ?
// #define DEBUG_THAT 1

// Output information on THEOTHER ?
// #define DEBUG_THEOTHER 1

// Determine if debugging support code is required
#define DEBUG 1
#ifndef DEBUG_THIS
 #ifndef DEBUG_THAT
   #undef DEBUG

With this procedure, if any of the DEBUG_* definitions are 'known', then DEBUG will also be. If none are available, then neither will DEBUG be.

My code currently contains eleven such clauses. I was wondering if I should curtail this. I mean, would the compiler max out at 16 nested definitions like OpenWatcom appears to offer? Maybe it tops out at 32 nested #ifdef statements, like the Microsoft compiler, like Delphi. What is the RISC OS compiler's limit?

It didn't take long to devise a test to check 50 levels of nesting. Which worked. I copypasted incrementally to take this up to 1,200 levels of nested conditionals. That worked too.

Now for the mother lode. This, obviously, needs to be done programmatically. So here's some drop-dead-simple code:

f% = OPENOUT("RAM:$.ifdefs")
FOR l% = 1 TO 65536
  n$ = "#ifndef "
  FOR r% = 1 TO RND(10)
    n$ = n$ + CHR$(RND(26)+64)
  BPUT#f%, n$
BPUT#f%, "#define OH_MY_GOD 1"
FOR l% = 1 TO 65536
  BPUT#f%, "#endif"
OSCLI("SetType RAM:$.ifdefs &FFF")

Running that generated a file of a little over 1.4MiB containing a massive, epic to the point of silly laughter, nested #ifndef structure containing a mere 65,536 items, all of which would be uniquely named. Plus the necessary 65,536 #endif statements.

Prepare to suspend belief. My project contains seven C sources and takes about 18 seconds to build all of that in its current state (changing the primary header file causes everything to be rebuilt - this is by design).
Plugging in the epic to the point of silly laughter nested #ifndef structure (which is dealt with seven times, remember) pushes the build time to 31 seconds. That means chundering through all of that rubbish nearly half a million times (65,536 × 7 = 458,752) adds a mere 13 seconds to the build time. Fu.......................kushima.

The picture on the right hand side? A snippet of the many many lines of random gibberish that doesn't faze the compiler one bit.

So, if anybody asks if there is a limit to how many nested #ifdefs that Norcroft / Acorn / ROOL's compiler can handle, just say this "many have set out on that quest, few have returned" and then walk away.



Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

No comments yet...

Add a comment (v0.11) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 93793 backwards.
Your comment
French flagSpanish flagJapanese flag
«   January 2016   »

(Felicity? Marte? Find out!)

Last 5 entries

List all b.log entries

Return to the site index



Search Rick's b.log!

PS: Don't try to be clever.
It's a simple substring match.


Last read at 03:49 on 2024/07/23.

QR code

Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0


© 2016 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.


Have you noticed the watermarks on pictures?
Next entry - 2016/01/25
Return to top of page