Simple Point Leak Question

[Re8eL]

Is this still a leak because its a point offset of a point?

• Set point2 = (((Position of Player_Unit[(Player number of (Picked player))]) offset by 65.00 towards (Facing of Player_Unit[(Player number of (Picked player))]) degrees) offset by (-17.00, -17.00))
• Custom script: call RemoveLocation (udg_point2)

 

[Just_Spectating]

nope, that still works.

 

[Re8eL]

Are you sure?

Leak check is picking it up as a leak, but leak check hasn't been very reliable.

I think it is because First it checks the location of the unit, than sets the point variable to a different point thats the offset, and the position of unit stays...

Edit: could actually be 3 points... Position of Unit(leak), offset by 65 at facing of unit(leak), offset by (-17,-17)(set as point2 and removed)

 

[Just_Spectating]

watch,

you set point2 to location of unit offset 65 facing Player_unit

x=unit
p=point2



_______X_______
_______________
______________p


not


_______X______
p_____________
|_____________
-> -> -> -> P_
______________

 

[Re8eL]

Was just told by a pro jassmasta that its 3 points and when that single point variable is destroyed, theres still 2 leaks.

 

[Just_Spectating]

well idk then..

 

[TehOwn]

Well, there's two options:

1) Your friend is an idiot and knows nothing about functions, returning, arguments or anything about real programming.

Or...

2) Blizzard are idiots and made an incredibly leaky language in which the functions load return variables onto the heap and are therefore not deleted when the scope ends.

Personally, I'd say that 1 is more likely than 2.

= Functions =
Player number of (Picked player)
Facing of Player_Unit[(Player number of (Picked player))]
Position of Player_Unit[(Player number of (Picked player))]
offset by (-17.00, -17.00) <-- some kind of simple modifier function
offset by 65.00 <-- and another

These functions are meerly passing values back, into your triggering function which is using them.

Global variables are leaks waiting to happen.

If the functions are leaky, then someone at Blizzard should have been fired.

At the end of the day, a few leaks here and there aren't a big issue UNLESS they are executed very often. It's just good practice.

 

[Re8eL]

I'm only arguing this because iv removed all leaks the normal way in the current alpha of my map, Which is a FPS, so it involves a lot of very frequent triggers, and after playing for awhile the game begins to slow and the movement becomes delayed. and this is not the result of bad triggering or to many triggers at once.


Are there Leaks that are unavoidable? If so, what are they?

 

[Vegavak]

I'm only arguing this because iv removed all leaks the normal way in the current alpha of my map, Which is a FPS, so it involves a lot of very frequent triggers, and after playing for awhile the game begins to slow and the movement becomes delayed. and this is not the result of bad triggering or to many triggers at once.


Are there Leaks that are unavoidable? If so, what are they?

POINT1 = (Position of Player_Unit[(Player number of (Picked player))])
WHATEVER = (Facing of Player_Unit[(Player number of (Picked player))])

POINT2 = POINT1 OFFSET BY WHATEVER

Do something with POINT2

Destroy POINT1
Destroy WHATEVER
Destroy POINT2

Have you tried this yet? Just curious.

I also hope you do something with point2 before destroying it.

 

[Just_Spectating]

i think offset is another leak, cause he said after he removed one that there was still 2 more leaks.

 

[Earth-Fury]

function PolarProjectionBJ takes location source,real dist,real angle returns location
    local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD)
    local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)
    return Location(x, y)
endfunction

function OffsetLocation takes location loc,real dx,real dy returns location
    return Location(GetLocationX(loc) + dx, GetLocationY(loc) + dy)
endfunction

Both leak, and unless I'm mistaken, both are used in your GUI code. (Location() creates a new location, thus the leak.)

 

[TehOwn]

Let me just explain to you guys something...

Location() is being returned by value, therefore not leaked. Return arguments are meerly created, copied and destroyed.

Is JASS really that idiotic that Blizzard would write it so that it wouldn't destroy local variables / objects?

Maybe JASS is a leaky language, I just figured that Blizzard were better than that.

Also, if you get a location, then return only the x from that location, you wont be leaking y. You'll just be wasting memory temporarily and cpu-time.

 

[Earth-Fury]

Let me just explain to you guys something...

Location() is being returned by value, therefore not leaked. Return arguments are meerly created, copied and destroyed.

Is JASS really that idiotic that Blizzard would write it so that it wouldn't destroy local variables / objects?

Maybe JASS is a leaky language, I just figured that Blizzard were better than that.

Also, if you get a location, then return only the x from that location, you wont be leaking y. You'll just be wasting memory temporarily and cpu-time.

All variables in JASS are 4 bytes large. (32 bits) All values are passed by-value. Any type that is not boolean, real, integer, string, or code descends from the handle type. Handles are pointers to locations on an internal table of handles. (Not all handles are like this. Some are just special constant values. player is a likely example, as well as anything who's only values are gotten from a GetConverted___(someInt) function.) Handles count references, but only via the "set" statement. This means that when a function returns, any and all handle-types which are locals of that function do not have their reference counts decreased. (Thus why you null locals.) There is a garbage collector in JASS, but it barely does anything especially when compounded with the issue of the broken reference counter. I reffer to handles which are created normally within the handle table as "normally created handles", as they are internally created and stored in the same way as all other "normally created handles". All handle-types which are normally created handles (and some abnormally created ones, like texttags) must be manually destroyed, except in the few instances where the game engine will take care of that for you. (Namely units.) If a handle object has valid references pointing to it when it is destroyed, then a placeholder is kept in the handle table so that any of the existing references to it do not become undefined in what they point at. (The broken reference counter fucks this up, of course.) Strings are also pointers. Strings point at an internal table of strings. Strings are immutable but supposedly recycled within the table.

FEAR MY WALL OF TEXT

In summary: Anything you create in JASS leaks, with the exception of the values the variables actually hold (Which for handles are either a constant, or a pointer.) and a few minor other exceptions such as units. If you do not manually destroy what you create, it will leak.

If I forgot anything or you want some clarification, it would likely be best if you posted about it in the JASS forum. (As this is defiantly offtopic for this topic.)

 

[TehOwn]

Thanks for that clarification Earth-Fury, I guess I was expecting too much from a simple language like JASS. I assume that they'd have destructors that would be called when the function scope ended. Seems ridiculous to have a leak caused by simple returning an object (by-value) from a function!

However, the language does do what it is needed to do. Kind of. And in most cases, 4-byte leaks are not going to be a massive issue. Of course, if you are going to have several functions that are run like every 0.04 seconds, then you will have an issue.

Personally, I usually use GUI and only really use JASS when I actually care about performance. I guess I'll get more into JASS in future.

This should definately be moved somewhere... Since it's kind of more to do with JASS at the moment, than GUI. Since this leak can't be prevented in GUI.

 

[Drone]

function PolarProjectionBJ takes location source,real dist,real angle returns location
    local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD)
    local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)
    return Location(x, y)
endfunction

function OffsetLocation takes location loc,real dx,real dy returns location
    return Location(GetLocationX(loc) + dx, GetLocationY(loc) + dy)
endfunction

Both leak, and unless I'm mistaken, both are used in your GUI code. (Location() creates a new location, thus the leak.)

I assume you're referring to a location leak in the caller functions of functions PolarProjectionBJ and OffsetLocation, if those caller functions don't remove the location and null their reference handle. The callee functions don't leak ofcourse, because the reference counter is properly adjusted when passing handle types as arguments.

 

[Earth-Fury]

I assume you're referring to a location leak in the caller functions of functions PolarProjectionBJ and OffsetLocation, if those caller functions don't remove the location and null their reference handle. The callee functions don't leak ofcourse, because the reference counter is properly adjusted when passing handle types as arguments.

Yes, but when explaining it to someone who barely has a concept of what a function is, one must take some liberty in the precise definitions

 

[Drone]

Yes, but when explaining it to someone who barely has a concept of what a function is, one must take some liberty in the precise definitions

I should stop being a smartass....

 

[Re8eL]

Well I just woke up, thanks for the clarification earth fury