I'm translating it now, it will soon be available on this site.

VD

Thank you for report, we'll fix that. For now I don't know what way will ADOLF choose, but he will certainly fix it =)

VD

ADOLF resisted implementing enum_name.enum_value notation, it's just enum_name for now :/ I'd like to have it like in C++, <s>but he's against doing it.</s> and he agreed to implement it =)

So this is just partially a bug as enum values are not yet implemented (now it's 0,1,2,...), but they will be.

VD

At first, I'd like to note than not everything is as simple, as you imagine =)

It's very possible that I'll implement local variables for increments/decrements in cases like postfix operations in if/return or prefix in elseif (but problems with more than one increment of the same variable in the return/if/elseif expression will still be present). Moreover, I'll implement variables when incrementing arrays with functions as index, eg:
<span class="code">i[GetRandomInt(0,1)]++</span>, that should become something like: <div class="code">temp = GetRandomInt(0,1)
i[temp]=i[temp]+1</div>

But I can't say for certain when I'll do that cause now there are some critical issues that require my attention. Now one of them is implementing native textmacro processing to avoid errors when compiling vjass maps, that use them heavily.

I'll also implement local variables for different scopes as it's necessary to add "for" loop, which is also in my to-do list.

As for assembler, well, my main job isn't related to IT at all, so programming is my hobby, it's somehow like a puzzle. Asm is not a programming language, it's more like a religion - very beautiful and elegant. I may be crazy, but this is my own way...

And thanks to VD for translating all this =]

The goal of cJass is to simplify the code and at the same time not make it more complex, so your proposal with variable for ++ was declined. ADOLF, anyway, will implement a fix for that return i++ behavior.

Templates are not yet in development cycle and I don't know how or when they will be implemented.

For now, no type understanding is implemented and not sure about that :( And I don't know if such way of using defines will ever be possible.

VD

Yeah, ofc in brackets =)

VD

ADOLF said that's a great idea and he'll do so. Thanks =)

VD

Yeah, I've just checked the C compiler logic with debugger and you're almost right: it first stores the previous value in some memory area and then takes the value again, increases it and stores to other memory area.

Unfortunately, we don't have low-level memory access in JASS, that's why we translate i++ the way it is (i;i = i + 1) not to complicate the code.

Anyway, we'll think what we can do with return i++ logical flaw in the future versions. I can't promice it will be fixed, but we'll definitely think about it =)

VD

Yeah, it was some lame bug, that seemed to appear and disappear occasionally for no particular reason.

We've already discussed templates with ADOLF and it seems they are not very hard to implement. And after they are here, you'll be able to write smth like
<div class="code"><b>template</b>&lt;T&gt; {
&nbsp;&nbsp;<b>struct</b> List&lt;T&gt; {
&nbsp;&nbsp;&nbsp;&nbsp;hashtable w_List&lt;T&gt; = InitHashtable()

&nbsp;&nbsp;&nbsp;&nbsp;...

&nbsp;&nbsp;}
}

List&lt;int&gt; mylist;</div>or even<div class="code"><b>template</b>&lt;T&gt; {
&nbsp;&nbsp;<b>define</b> &lt;new List&lt;T&gt;&gt;(x) = List&lt;T&gt;.create(x)
}</div>Not quite sure about defines in templates, but who knows =)

VD

<a name="constants-vs-values"></a>Here's the JASS code, which we're going to disassemble:
<div class="code">constant real x = 0.
define xx = 0.

void fx () { real const = x, def = xx }
</div>
And here's what operations we've got when the above code is run by the game's JASS interpreter:
<div class="code">08C9E0A0 fx+0000 00 00 05 05 00000eaf &nbsp;&nbsp;&nbsp; CREATE_LOCAL const {real (5)}
08C9E0A8 fx+0008 00 05 68 0e 0000024a &nbsp;&nbsp;&nbsp; <b>MOV_VAR_REG x => #68 {real (5)}</b>
08C9E0B0 fx+0010 00 00 68 11 00000eaf &nbsp;&nbsp;&nbsp; MOV_REG_VAR #68 => const
08C9E0B8 fx+0018 00 00 05 05 00000eb0 &nbsp;&nbsp;&nbsp; CREATE_LOCAL def {real (5)}
08C9E0C0 fx+0020 00 05 69 0c 00000000 &nbsp;&nbsp;&nbsp; <b>MOV_VAL_REG 0 => #69 {real (5)}</b>
08C9E0C8 fx+0028 00 00 69 11 00000eb0 &nbsp;&nbsp;&nbsp; MOV_REG_VAR #69 => def
08C9E0D0 fx+0030 00 00 00 27 00000000 &nbsp;&nbsp;&nbsp; RETURN
08C9E0D8 fx+0038 00 00 00 04 00000000 &nbsp;&nbsp;&nbsp; STUB_FUNC_END
</div>
As you see, on line 2 the value is taken from the memory area, corresponding with the constant address and placed to the register (it's in bold text). Then the value in the register assigned to the local variable at line 3.

On line 5, direct value is placed to the register (it's in bold text), and then assigned to the second local variable at line 6.

If to make an example in plain asm, the difference is the same as the difference between these two statements:
<div class="code">mov eax, dword ptr [40000000h] <i>; address</i>
mov eax, 10h &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;​&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>; value</i>
</div>
In the first case, you have to look the memory for the address, then find what value is in that memory area and then move the value to the register.
In the second case, you just move the value to the register - it's much faster.

That's why in cJass defines do direct value substitution.

Yeah, we know about that logical flaw, but I don't know if or when it will be fixed.

As for function interfaces, I didn't come to any reasonable way to write it in C-style and leave easily understandable. Function pointers are not yet here, but I'll add them to out to-do list =)

VD

I think that's a question to adolf cause he knows a lot more about memory organization and so =) I'll ask him.

VD

It's ok, I've tested it with correct code and it isn't working if there are more code in the map :( I'm trying to find out what's causing the mess.

VD

I'll see what I can do

VD

Yeah, I see. I'm trying to find out why it's failing

VD