Leak or overlap

[W!†A_cRaft]

Would this leak or overlap the data? Since i did not remove the 1st temp_point before setting another, though it should have just replaced the one used before yes?

• Untitled Trigger 001
  • Events
  • Conditions
  • Actions
    • Set Temp_Point = (Center of (Playable map area))
    • Unit - Create 1 Footman for Player 1 (Red) at Temp_Point facing Default building facing degrees
    • Set Temp_Point = ((Center of (Playable map area)) offset by (150.00, 100.00))
    • Custom Script: call RemoveLocation(udg_Temp_Point)

 

[Nenad]

I would remove the tempPoint after each use, just in case (you lose nothing by doing so ^^)

 

[Wratox1]

that leaks, since you do not remove the first point you set, you have to remove it after you have created the unit

 

[Endurance]

As to the Question:

- Yes, the Variable is replaced.
- No, it does leak. Either destory the location after use, or use integers.

 

[W!†A_cRaft]

so correct me if i am wrong here:

when i make a variable Temp_point it tells the compiler/assembler that i want to allocate a space in memory for later use, now I set the (center of playable map area) to be held as information inside this allocated space.

Next, i do not free space, i just tell it to get different data into it, thus basically erasing what was already in it, why does this leak? New space in memory was never alocated

 

[Endurance]

Next, i do not free space, i just tell it to get different data into it, thus basically erasing what was already in it, why does this leak? New space in memory was never alocated

You said it, you do not free any space. Overriding not equal to erasing.

 

[W!†A_cRaft]

how come? if i take the same space in the memory and override it, the data that was there before is never reachable again but the new data does not occupy new space, it uses the one from before thus the "old" data doesn't leak it is in fact gone, no?

for example, when i start a map i am using up 50 MB of space on RAM, with 1231231231123131 runs of this trigger i'd again use only 50 MB of ram, no new allocating has been done

 

[Endurance]

This is pretty interesting, indeed.
Yet again, I would clear the temp variable before I assign a new value.
Whether it leaks or not, we could keep on debating for hours. :nuts:
From my point of view, it would be "better" to clean up the leak and re-assign. :thup:

 

[W!†A_cRaft]

Will tend to do that i was just interested in if it does leak or not
Because it is really giving me a freaking :banghead::banghead::banghead:

 

[Endurance]

I am not really familiar to the Wc3 Engine, thus I can only speculate.
Overlapping variables in c++ leaks, because they are stored into the memory.

 

[Sgqvur]

>with 1231231231123131 runs of this trigger i'd again use only 50 MB of ram, no new allocating has been done

The execution of this trigger creates creates 3 locations(points), 1 unit then frees the last location(created in the OffsetLocation see below). You need to "expand"(convert to custom text) the GUI to look what's happening underneath the hood.

In fact the location constructor is called 3 times: 2 by Center Of function(GetRectCenter) and 1 time in the OffsetLocation function.

Your last line of code removes only the last location that was returned by the OffsetLocation function

You would need to use 2 location to properly "free" memory.

• Untitled Trigger 001
  • Events
  • Conditions
  • Actions
    • Set temp_loc = (Center of (Playable map area))
    • Unit - Create 1 Footman for Player 1 (Red) at temp_loc facing Default building facing degrees
    • Custom script: call RemoveLocation(udg_temp_loc)
    • Set temp_loc2 = (Center of (Playable map area))
    • Set temp_loc = (temp_loc2 offset by (150.00, 100.00))
    • Custom script: call RemoveLocation(udg_temp_loc)
    • Custom script: call RemoveLocation(udg_temp_loc2)

Note that the example leaks a unit : )

 

[W!†A_cRaft]

>with 1231231231123131 runs of this trigger i'd again use only 50 MB of ram, no new allocating has been done

The execution of this trigger creates creates 3 locations(points), 1 unit then frees the last location(created in the OffsetLocation see below). You need to "expand"(convert to custom text) the GUI to look what's happening underneath the hood.

In fact the location constructor is called 3 times: 2 by Center Of function(GetRectCenter) and 1 time in the OffsetLocation function.

Your last line of code removes only the last location that was returned by the OffsetLocation function

You would need to use 2 location to properly "free" memory.

• Untitled Trigger 001
  • Events
  • Conditions
  • Actions
    • Set temp_loc = (Center of (Playable map area))
    • Unit - Create 1 Footman for Player 1 (Red) at temp_loc facing Default building facing degrees
    • Set temp_loc2 = (Center of (Playable map area))
    • Set temp_loc = (temp_loc2 offset by (150.00, 100.00))
    • Custom script: call RemoveLocation(udg_temp_loc)
    • Custom script: call RemoveLocation(udg_temp_loc2)

Note that the example leaks a unit : )

yea yea, we were only focusing on discussing a Temp_loc leak, offset leaks and unit leaks but that wasn't the point

I was just interested in if the trigger would leak if i override the data without removing it before.

 

[luorax]

I'm not a C++ expert (I still learn it), so correct me if i know something wrong:
-when you call "local location tl" then it creates a new pointer ( tl = new location; ), what's a NULL pointer basically
-when you set it's value to someting (like tl = Location(X,Y), then it creates a new location type variable, and make the "tl" variable (pointer) to point to the new location
-when you create a new Location, and make the "tl" variable, to point to the new location, then the old location's still in the memory, and because we've lost it's address, we're unavailable, to remove it. So it'll leak, and we're unavailable to remove it. That's why we need to remove the location, or create a new variable (pointer) to store it's address.

But this's my opinion. As i said, i'm a "student" not an expert.

 

[W!†A_cRaft]

you are quite possibly correct.

 

[Accname]

what luorax said is correct. basically this is the very same procedere like in any programming language but the most of todays scripting languages use some kind of build in garbage collection which takes care of leaking objects. they would be auto-removed. but not in wc3.

 

[Ashlebede]

most of todays scripting languages use some kind of build in garbage collection which takes care of leaking objects

Read : JavaScript, Lua, ActionScript & pretty much every high-level programming language. When a variable that pointed to an object changes value, it will be checked whether or not it was the last pointer towards that object. If it was, it will be eligible for garbage collection. In GUI/Jass, you have to garbage-collect it yourself. It is not a high-level language like the above.

 

[Accname]

@Ashlebede:
wasnt that exactly what i said? if not that was what i meant.