C preprocessor in jasshelper
Do you think jasshelper should have C preprocessor?
I uploaded experimental version with C prepreprocessor, try it and vote.
I've voted yes, because actual text macros are not only really limited, it's also fugly to use.
Not to mention that hooks are most of time useless in the current state.
And finally i've always found the use of static ifs not enough clear with the actual syntax (i mean the syntax difference between static ifs and classic ifs is not enough)
But public resources shoudn't use bigdef for a native function define.
Btw, is it possible to define a native function instead of using it like vJass textmacros ?
EDIT : Ok, just tested and you can.
A pretty new toy to play with it, i would say :
Why bigdef and just not def, or define btw ?
EDIT 2 : Oh wait, i was trying to define RemoveUnit for my Personnal Unit Indexer, but sadly it defines also GroupRemoveUnit, and i suppose anything which have RemoveUnit in its name :/
I'm also wondering if it defines strings "" (can't test it right now).
EDIT 3 : bigdefs are considered even in comments block (/* */), plus i tends to add line breaks and make a new line with the last character (usually a ")" ) and then make the jass script invalid.
So if you plan to let them in the current state, you should just remove them instead.
Ofc you are welcome to improve them, if you're willing to it.
#bigdef is for multi-line macros.
#define is for one-line macros.
It seems all your problems can be simply solved by reading the manual.
Humm, maybe it is just the new year thing but it seems there are not enough people to even make a decent poll.
(or not enough people willing to learn something new)
Anyways I will probably put a turn on/off option (default off) for C preprocessor in jasshelper menu bar since it does not seems it is gonna be uber-mega-popular.
(which is a shame considering how easy it is to use)
I would find #define to be useful, but not the others. Perhaps also #foreach, to replace short loops with something more efficient. But the other features seem (to me) either useless, or uglier alternatives to what exists.
For some reasons i didn't saw the documentation, neither #define, my bad.
Anyway, unless a space " " is a valid first character for a #define i fail to see how to define RemoveUnit, without breaking other functions such as GroupRemoveUnit.
Or maybe defines will work as intented without the need of a space, i can't test it now.
Same for this :
I can't even use the tool in command line before jasshelper to remove comments, since it will also remove all external commands (//!...)
Also, i have not tried yet but i'm stll wondering if strings "..." are affected by the defines.
And also not tested, but i suppose you handle requirements (library A requires B, scopes, ...) before doing any defines, else that wouldn't work that much.
Anyway thx for this and jasshelper, i had almost no interest in wc3 modding but you gave me some.
Most parts of macro preprocessor have already been implemented by vexorian,
the problem is they do not all look like preprocessor constructs.
The last three clearly do not look like preprocessing statements but rather like jass extensions.
This kind of programming stile is misleading.
As for comments on the estetics of this stuff vs C preprocessor directives,
I think that should have to wait for someone to make proper color coding for #statements.
Here is a tip for your particular problem:
Make a macro for GroupRemoveUnit before you make a macro for RemoveUnit.
Removing comments has been disabled so preprocessor would not destroy old external commands and textmacros. Compatibility ftw.
There is an option to turn it off but I see no reason for it.
That way you can do things like this:
Of course optional keyword does the same in one line,
ifdef PUI library mylib uses PUI elif Autoindex library mylib uses Autoindex else error "mylib needs at least one indexing system" endif
but than again it does not error if you have both libraries at the same time
or if you don't have either.
compiles to :
I've also tried to use GroupRemoveUnit instead of that awesome BJ created by myself : same result.
Or i'm missing something ?
What i mean is that it doesn't make sense that preprocessors are evaluated if they are commented, they should be disabled.
Leave a tag option in the file jasshelper.conf wouldn't hurt.
Well, the real problem is that the wc3 editor doesn't handle really well relative trigger order
So requirements are a must, and also despite some people says, really most of the time scripting inside the editor is the only way to go (preplaced units, object editor stuff, ...)
It breaks the concepts of vJass requirements, which is not a plus here.
Now, if it is just too much and/or will make the compile time much longer, i think you should just leave this stuff.
You have no idea of what you did.
Preprocessor directives exist before everything else, even comments.
Therefore putting them inside multiline comments /* */ will not work
To disable a preprocesor directive use single line comment before directive //#
Give longer argument names for macro params and make sure they don't appear as part of other macro names.
call GronullpRemoveUnitBJ(null , null) // u -> null
"u" is obviously a very bad name :)
Try something like UNIT
I still don't get how the jass code is generated in my example, for me it's a bug.
But well, i've changed the macro param name and it works.
Too bad we can't define a function to itself and make a wrapper of it instead, sure it will be inlined but meh ...
This preprocessor is far more powerfull than what we already have in jasshelper, but i wouldn't say :
Actually it is not, and quite tricky.
Also considering that most of the stuff you allow shouldn't be used in a public ressource, i repeat myself, this preprocessor should be removed, even if i've voted yes in the first place.
Well it is easy to use to me, but I guess that is because I know C programming, so I don't really count.
That is it I guess.
C preprocessor will be removed because:
It would have been a great thing if it was inserted at the beginning of jasshelper development,
but now it is a bit late for it.
Next jasshelper version will have no C preprocessor.
|All times are GMT. The time now is 08:14 AM.|
Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services