• Create Account

Banner advertising on our site currently available from just \$5!

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

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

### #1kozec  Members   -  Reputation: 118

Like
1Likes
Like

Posted 21 March 2013 - 06:39 AM

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.

### #2Andreas Jonsson  Moderators   -  Reputation: 3780

Like
0Likes
Like

Posted 21 March 2013 - 04:16 PM

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.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #3Andreas Jonsson  Moderators   -  Reputation: 3780

Like
0Likes
Like

Posted 26 March 2013 - 04:52 PM

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

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

### #4kozec  Members   -  Reputation: 118

Like
0Likes
Like

Posted 04 April 2013 - 07:32 AM

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, 04 April 2013 - 07:44 AM.

### #5Andreas Jonsson  Moderators   -  Reputation: 3780

Like
0Likes
Like

Posted 04 April 2013 - 11:16 AM

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
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS