Bug with the anti bj:

if chatGroup != PD[pid].AlienChatGroup then
DisplayTextToForce(chatGroup.ScannedPeople, chatGroup.Prefix + " " + name + chatGroup.ParsedString)
else
//Hay, they be aliens!
if PD[pid].Cerebrate then
name = "|cff440000Cerebrate:|r "
endif
DisplayTextToForce(chatGroup.ScannedPeople, chatGroup.Prefix + " " + name + chatGroup.ParsedString)
endif

Raises an error of missing an end block: with some creative digging, I found that it compiled to:

if chatGroup!=PlayerData[pid].AlienChatGroup then
if IsPlayerInForce(GetLocalPlayer(),chatGroup.ScannedPeople) then
call DisplayTextToPlayer(GetLocalPlayer(),0.,0.,chatGroup.Prefix+" "+name+chatGroup.ParsedString)
else
if PlayerData[pid].Cerebrate then
set name="|cff440000Cerebrate:|r "
endif
if IsPlayerInForce(GetLocalPlayer(),chatGroup.ScannedPeople) then
call DisplayTextToPlayer(GetLocalPlayer(),0.,0.,chatGroup.Prefix+" "+name+chatGroup.ParsedString)
endif
endif

That anti bj in the second line is converted to an if with no end block.

Commenting out

#include "cj_antibj_base.j"

Fixed the problem.

If we could get a fix, it would be great please.

I've suggested ADOLF to switch to cjass-only blocks, dropping support of plain jass syntax and leaving a compile-time flag, that turns on old behavior (compiling all map in cjass). He said he'd think about it.

b) forbid using old syntax if statements without then, ie:
if (true)
doSomething()
endif

will give a syntax error

>Stop trying to merge them, otherwise we go into all of these ambiguities. Each line in a c jass block needs to be treated as pure cjass.

There are two ways of solving the "single statement if" problem:

@ VD: wtf is with that underscores?

yeah, duno in jass u even cant declare func or var starting or ending with underscores...

anyway this ifs could just be compiled to:

if (expr);

now u dont need to check is it in same or next line...

that what u write as syntax error should actually be possible and its actually the main reason why we would like single lined ifs...

if (u != null) KillUnit(u)

Greets and if possible plz fix that last bug with anonym funcs, thanks!
~DD

Single line block statements are a part of C : |... the { } signifies multi line block and no { } signifies single line...

And all the arguments against it are wrong.... trying to do endif etc.. that's not a part of C is it? Remember, making this better would require it to be in a language block... JASS should be the only language allowed that isn't in a language block, and vJASS as it's really an extension to plain old JASS.

if (expr) // syntax error

that shouldn't be a syntax error because you can't do if then endif in cJASS anyways... : |

Stop trying to merge them, otherwise we go into all of these ambiguities. Each line in a c jass block needs to be treated as pure cjass.

wtf is with that underscores?

Maybe:

if (expr) // syntax error
____action()
// without endif

?

The only way syntax
_if (cond)
__action()
is good, is to forbid syntax
_if (cond)
__action()
_endif
because they are too similar.
When "then" was needed it was like a "{" to wait an "endif" like "}".
One line if syntax
_if (cond) action()
is good because it has flag needed - one line.
Please do not allow coders to do such a stupid errors.

And do something to allow formatting code here.

ofc if user writes endif or uses {} then it will compile all actions inside but if coder writes only "if/else" then it will automaticaly add endif after next action.

if (expr)
act1()
else
act2()

currently we would need to use {} or endif...

It is too easy to make a mistake.
And may be hard to find it.
Map author can write:

if bool1
_func1()
_func2()
_if bool2
__func3()
_func4()
endif

...and you will compile it wrong.

Please do not do it.

Let be two variant.

if (cond) act()

and

if (cond)
act1()
...
actn()
endif

or yet another

if (cond) {
...
}

if (expr) act()

compiled to:

if (expr); act(); endif

if (expr)
act1()
act2()

compiled to:

if (expr)
act1()
endif
act2()

// new syntax
if (expr)
// witout endif

It is wrong syntax.

if bool1
func1()
func2()
if bool2
func3()
func4()
endif // which if are you choose???
//You can think different with author

if (expr) action
This is good. If someone do not want to write endif, he can use {}.

Well, then our roadmap is:

// old syntax, only add "then"
// I'll check "endif"
if (expr)
//...
endif

// new syntax
if (expr)
// witout endif

// compile to
if (expr)
endif

// and:
if (expr) action

// compile to
if (expr)
action
endif

ternary operators, and all other features we add after it)

Thanks a lot for this update ADOLF!

funcs finaly work and there is just one remaining bug about them.

define ForGroup(g, f) = For##Group(g, f)
define ForGroup(g, f, v) = { temp = v; For##Group(g, f) }

if i use lambda funcs as argument:

ForGroup(g, lambda nothing() {})

will not compile.

anyway thanks for all ur time spent on making cJass its really awesome project and lambda funcs really help me in making my code more readable and easier to write.

Thanks!
~DD

If I remember correctly aim was not to "make C on Jass".
Aim was to Jass, vJass and c-like syntax can be uses simultaneously.

About a=3+(b=2*2)
Looking at precedence in Bjarne's book you can find what "=" have lower precedence whan "*". And "?:" even lower. So your example must be...
percent = ( (a > 0 && a < 1) ? a*100 : (a > 0 && a < 100) ? a : 0 )

->if (a > 0 && a < 1) then

set percent = a*100
elseif (a > 0 && a < 100) then
percent = a
else
percent = 0
endif

But leftmost "=" is a part of "set var=" syntax, so it is out of precedence table and must be always last.

Actually, you should try to stay as close to the C standard as much as is possible.

Yeah, this language definately needs to become more like C. More than it already is.

Then it may become more popular.

Sry for the third comment, but something is very confusing as I had a typo : ).

->introduce protected keyword and structs within structs

: D, all fixer uppered now

Oh.. forgot to mention this, but instead of each ObjectMerger call etc having to extract the stupid files from the MPQ archive, you should auto extract all of them into a directory for processing, not just the JASS file. In this way, people can manipulate them on the fly with preprocessing stuff or they can use an exe like ObjectMerger to mess with them. You could add in soem preprocessor commands for manipulating them though.

Oh yea, introduce protected, structs and within structs. I'm also working on a pretty nifty collections framework, so when I've finished with that I can give you the code and you can put that all in as part of the standard too. They are very generic and work completely through preprocessing directives, so it wouldn't add to the map size at all.

a=3+(b=2*2)

is not
set b=2*2
set a=3+b

the b would be 2, the a would be 3+(b*2)
or
int a
int b
b = 2
a = 3+(b*2)

I think you wanted a = 3 + b=(2*2)

A preprocessor cannot determine how many characters to apply to a variable, so it would go for the first value. Grouping is done through ().

And for all this crap about multi ifs in ternary...

percent = (a > 0 && a < 1) ? a*100 : (a > 0 && a < 100) ? a : 0

there's a perfect example of multiple ternary operators in one line -.-...

you guys are overdoing it, just follow C Syntax... /sigh

Also I think that all lines that aren't blocks should must end with ; and that lines that don't end with that and aren't blocks should be merged with the next line.

Furthermore, blocks without { } will be treated as though they only have one line, ( ) required on boolean expressions to determine when they end, and etc... all the normal C stuff..

You're shooting for C Syntax right? Then stop trying to merge C and JASS together -.-...

Also, you should be able to extend handles.. like extend unit. When you extend a handle, it'd be like methods in vJASS structs, except instead of integers they'd take a handle type called this. Also they're create would be just the handle create. In this way, all current natives could be transferred to an OO syntax without any performance hit.

Furthermore, extends should be changed into : to follow C Synatx -.-. All cJASS should be required to be placed in C Blocks. Follow language conventions -.-. You can't just merge two languages together... it all turns messy, this is the primary reason so many people are so opposed to cJASS right now.

All preprocessor directives in cJASS should be # instead of //!... and the current ones should always require #, including define and include.

also, make define more like a normal C Define...

For further preprocessing, allow people to define their own languages. The language blocks should include a block name, which blocks they use, and the language's interpreter (exe). You should auto provide euphoria as it's part of grimoire.

Also give people access to the JASS file in an XML format... so if there are any preprocessor language blocks in the file, output the JASS file to the XML format including so that the interpreted scripts and read them in, and then convert XML back into JASS file and start on your cJASS, and from there, direct the file to vJASS... don't direct it to vJASS in the Lua file for grimoire, direct it within cJASS...

So when you think of these language blocks, think-

#external (blockname) uses [blocks] with exe {
}

For blocks that use different exes, just runt he previous blocks first... for blocks that run on the same exes, merge them so they can use the methods and data etc... For Lua, it'd just be-

#lua (blockname) uses [blocks] {
}

//! lua is a decent temporary measure as you mentioned before, but do it right.

Also I've noticed a LOT of problems with #if... sometimes when the thing is true, it'll equate to false... sometimes when it's false it'll equate to true. I've had to go through a bunch of crap when using it : p.

Many ++/-- in one strings do not look better.
Such nested "?:" operators are easy to get mistake if preprocessor not used.
I think local is not needed for such forked return.

Also what can you say about:
integer a,b
a=3+(b=2*2)

->

integer a
integer b
set b=2*2
set a=3+b

Is not it a good work for preprocessor?

thats an nice idea on how to implement single lined ifs Sebra!

it does not require vars, funcs nor anything and is inlined ofc... there are rare cases where 2 ifs would be used in same line but i can already immagine few of them. ofc they should work if two or more are used in same line but what i wanted to say is that there will be rare cases where there will be a lot of jass lines... as this will get compiled to n_ifs^2... so more ifs in single line the much more lines, however amount of code does not matter since in truth only n_ifs are executed rest is skipped...

if you decide to implement this ADOLF it will be awesome and i think the way Sebra explained would be the best one.

int test() { return (true)? 1:0 }

that code would not work but we can always write:

int test() { return (true)? 1:0; return 0 }

if you want to make it work in returns as well then you might want to use one local, through i had hard time fixing cjass locals from "++" stuff as if i return handle i cant use ++ coz it will leak...

anyway i am most interested in lambda funcs and i hope they get fixed asap ;)

Greets!
~DD

Many things from C become too complicated on Jass.

Why are people complicating it... just make it like C... this is cJASS after all -.-...