Q about Boolexprs and leaks

[bOb666777]

First off, I'm pretty confident they do, but,
Do boolexprs leak?

And if so, how can I prevent that?

I tried setting a local to it
then using it
then destroying it,

But then my function acts like if i put null instead of a filter...

Here's what I put:

local boolexpr filter = Filter(function Thunder_filter)

Is there anything wrong with that, and what?

 

[phyrex1an]

Boolexpr doesn't leak and doesn't need to be destroyed.

Check the wiki http://wiki.thehelper.net/wc3/Boolexpr

 

[bOb666777]

However, future boolexprs that use the same function such as this:

Condition(function ReturnTrue)

will return the existing boolexpr, rather than create a new one. For this reason, it is not necessary to destroy boolexpr variables.

Does that mean I don't have to create a local at all, or does is mean I don't have to destroy it?

 

[phyrex1an]

Does that mean I don't have to create a local at all, or does is mean I don't have to destroy it?

You don't have to destroy it. It doesn't make either or for the local.

 

[Darthfett]

Does that mean I don't have to create a local at all, or does is mean I don't have to destroy it?

1. It doesn't leak like a location or a group would leak. You don't have to destroy it unless you know you're never going to use it again (and even then it barely makes a difference, unless you're creating hundreds of these things from different boolexpr functions).

2. It doesn't leak a handle unless you destroy it. That means you don't have to set it to null unless you're going to destroy it.

 

[Jesus4Lyf]

Lol, I Googled this issue, found this thread, and was going to necromance it to ask this, but suddenly realised it's only a few hours old anyway...

I challenge your notions that boolexprs don't leak.

My tests showed me for sure that:

• Conditions don't (unless you destroy the, and I don't know how to avoid the handle leak then, nulling didn't seem to help, but it didn't seem to help for removing locations and unit groups either).
• Filters are the same as conditions.

And...

The And(boolexpr1, boolexpr2) and Or(boolexpr1, boolexpr2) boolexpr generators DO seem to leak. And I can't make them stop. How can you clean up these leaks? Please proove that it works. As in, here's my code, show me yours, spitting out the same handle id or whatever it should do if it doesn't leak...

globals
    trigger t=CreateTrigger()
endglobals
function A takes nothing returns boolean
    call BJDebugMsg("A")
    return true
endfunction
function H2I takes handle h returns integer
    return h
    return 0
endfunction
function TestCode takes nothing returns nothing
    local integer i=0
    local boolexpr b
    local boolexpr af=Condition(function A)
    loop
        exitwhen i==100
        set i=i+1
        // Do things
        set b=And(af,af)
        call BJDebugMsg(I2S(H2I(b)-0x100000))
        call DestroyBoolExpr(b)
    endloop
endfunction

But my other problem is I can't even remove locations or unit groups and have handles repeat! What's going on?! Is repeating handle IDs not a sign of leaks?

Educate me!

Thanks,
Jesus4Lyf.

 

[Troll-Brain]

You forgot to null b after the loop.

Anyway does anybody has ever already used "And" , "Or" ?!

 

[Jesus4Lyf]

You forgot to null b after the loop.

That's not the problem. That would make 1 leak, not 100.

Anyway does anybody has ever already used "And" , "Or" ?!

The new version of Key Timers 2 coming soon will use it. This has allowed it to become the fastest timer system to date without losing the interface it has.

Anyway, here to answer my own questions...
Handles are not freed until you have some sort of wait. So adding TriggerSleepAction(0.1) to the loop fixes it.

"And"/"Or" (and maybe "Not" I assume) boolexprs are not recycled according to their inputs, and must be freed using DestroyBoolExpr(boolexpr) after use, or else they leak (the wiki should be updated).

"And" and "Or" use short circuit evaluation. Meaning if the first of "And" returns false, or the first of "Or" returns true, the second is not evaluated. This has pretty much one very rare and strange use, which will be in KT2, and only facilitates a nicer interface. See the last post if you're that interested.

:shades:

Edit:
Even more.

Destroying boolexprs created with And/Or (and probably Not) once they are attached to a trigger will actually cause them to fail. You must not destroy them until they are no longer used.

PS. I updated the wiki.