ANY way to hack your own ifdef directives?
BlitzMax Forums/BlitzMax Beginners Area/ANY way to hack your own ifdef directives?
| ||
| Because, I could *really* use them for my behavior system. Otherwise, I'll end up releasing two versions of the source code as doing if/else checks in the code where I *should* be using an ifdef directive will slow the code down considerably. It'd be easier to just release two different sets of source code or two different modules. |
| ||
| There is a modified BMK with preprocessor support for ?define ?ifdef ?endif ... Otherwise: Use a const and IF with that, that will be much faster than using variable IF checks (although not as good as it was in old blitz that removed the "jumped" block completely from compile) |
| ||
| Hmm, looks like I'll just stick to maintaining two separate source code versions then, as the changes not only entail some IF checks, but also require the definition of some other fields that will take up unnecessary amounts of data when not desired. I thought about just using ?debug but would like to offer the end users more variety than being forced to build a debug version to utilize variable tracking. (because it's conceivable they could want the variable tracking system to work on a release version, for a level editor or something.) |
| ||
| You dont really need two seperate source codes entirly. You just have two small loader/starter files import stuffforthisbuild include stufffirthisbuild1 go import stuffforthisbuild2 include stufffirthisbuild2 go OK so it means some work to ensure that the ?Ifdef bits are all in seperate files, but this would be a lot less work than maintaining two different sources would be |
| ||
| Well, I can kind of do that H&K, but a few files the changes are so numerous that I really will need to keep two separate versions of them. It's going to be a bit of a pain. |
| ||
| You could always use GCC as a preprocessor. Its not a perfect solution, but at least you dont have to maintain two separate versions (which would definitely be a pain). |
| ||
| I cannot agree with Grable more, wether you chosse a preLinker, or manualy include, definatly dont stick with two sources. but a few files the changes are so numerous that I really will need to keep two separate versions of them I assume you mean that it would be a lot of work splitting the files. If that is what you mean then please take my advice and do split them. At its simplest, dont include a file, but include one of two includes, that then includes different versions of the include lists of that file split up. If you do deside to continue with two/more souces, please ensure its the only possible solution, because nearly anyother solution would be better in the long run, even if the ground work would seem to take longer. |
| ||
| What is actually the problem with setting a const in a file that is included in ALL sources? Which either sets or not sets a const? Where is the actual difference to ifdef there? Can't see it, perhaps you just think of all that stuff the wrong way round or too much in C++ terms instead of BM terms (bm is not C++ and has some major behavior differences) |
| ||
| It's really just a specific problem that affects my design for my Behavior system. It utilizes hash tables to store variables of any type, and with any name, but to properly view these variables and edit them during runtime via an editor or something, the system needs to track the type of the variable. This involves a change to the underlying hashtable and how it stores entries, and also changes a lot of function calls to include the type parameter, check the type parameter to verify it's valid, etc. Basically, the system is going to take up a lot more memory and run slower when it's tracking the types of these essentially dynamic variable slots, and most games won't need that once the game is finished and all the testing is done, so there's no need for the code to execute, and there's no need for the extra tracking entries in the hash table, etc. So, basically, I plan to create two distinct versions (although all function calls will be identical, it's just some parameters will be ignored with the variable tracking off), and the programmer can then compile their code with the release module when they no longer need to track variable types or need the functionality of being able to see any/all variables and their values in an object at anytime (although that functionality will be quite handy when testing/debugging.) It'll be clearer once I get to the point where I can release an early version of this system. |
   |