# C/C++ like #define directive (patch attached)

This topic is 1754 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi!

There is one thing I really missing in AngelScript. Constants. I really like constants and have lot of 'em in my code, and it is real pain when I have to copy-paste-adapt them to script files.

So I modified CScriptBuilder addon to enable #define directive and, when I was on it, #ifdef and #ifndef directives as well. This way, I can safely share my .h files between c++ and AngelScript with little compile time overhead and no memory loss.

And I thought I may share it as well - modified CScriptBuilder.c, CScriptBuilder.h and patch against files from Angelscript 2.26.1 SDK.

This patch enables following:

• C-style #define directive, but usable only for constants - no parametric macros
• Anything #defined as 1 or true is stored as "defined word" as well, so standard AngelScript's #if works with it
• C-style #ifdef and #ifndef directives, looking for both "defined words" and macro names
• Ability to negate #if directive with ! character ( #if !LINUX ... #endif )

and it shouldn't break any working code.

Only drawback is that it's using std::map to store macro definitions and that thing is not exactly speed daemon, so having lots of constants may prolong compile time (almost every word in script is compared to every defined macro.) I'm planing to code some more optimized map for this, but I wanted to keep thins simple for start.

##### Share on other sites
Thanks for sharing this enhancement. I'll review the changes and incorporate it into the sdk.

I'll probably add a flag for enabling or disabling constant replacement so the lookup can be avoided if it's not desired. Especially if it is something that impacts performance.

##### Share on other sites

I was reviewing the changes you made, and I see a flaw in the solution. Previously included files wouldn't have any effect on each other since the preprocessor didn't allow defining new macros/constants from the script. For this reason it was fine to preprocess each file separately. You obviously noticed this as you changed the code to do the macro substitution only after included files had been processed, which is enough for what you do I suppose.

But if an include file defines some macro that should be used to determine what other include file to process, then it won't work. For example:

#include "target_defines.as"
#if LINUX
#include "linux_specific.as"
#else WINDOWS
#include "windows_specific.as"
#endif


To work correctly the preprocessor needs to stop processing the current file when it encounters an include directive, then continue from the same spot only after the included file has been processed. The macro substitution must also be done in the same pass, otherwise you may have end up making substitutions in the code above the declaration of the macro itself.

This was one of the reasons why I hadn't implemented a fully working preprocessor in the first place. I may hold off on including your patch in the SVN until I have the time to make the correct implementation, though I haven't decided yet. I may just add a few todo's for a later improvement too.

Regards,

Andreas

##### Share on other sites

You are right assuming thatm I implemented only as much as my own project needed, but I don't see fixing this as that big problem. Maybe I'm missing something?

Here is modified CScriptBuilder, patch and sample code that has said problem fixed (or I rather hope, but I made some tests and it looks good )

I moved #if preprocessing and entire inclusion before everything else is done, so, as You suggested, when CScriptBuilder encounters #include directive, it recursively calls AddSectionFromFile (or includeCallback) and rest of file is processed only after entire included section is added and parsed for #defines. This way, defining macros in included file and using it right away is possible.

But with this way of including, order of sections is reversed and included sections are added before section that includes them. To be honest, I'm not sure what, if anything does this mean. Does order have any importance?

Edited by kozec

##### Share on other sites
I didn't say it would be difficult to fix, just that I hadn't done it yet. :) Thanks for making the changes. It will save me time to focus on other enhancements. The order the script sections are added to the module doesn't matter. AngelScript's compiler is designed to be order independent. All global entities are visible to all other global entities. Regards, Andreas