BoolExprs...

It is not a myth: The native called Condition and the native called Filter use some kind of caching so



WILL show surprise.

This is not the case for And(...,...) , Or(....,...) and Not(...) those do always create new BoolExprs.

This actually means that destroying one instance of Condition(function a) will actually destroy all the previously created instances of it.

And this also means that some blizzard.j functions might be really dangerous.

Have a nice day.

thats not good... Well, technically, if the map is strictly JASS, one shouldn't have a problem since all boolexp should be accounted for, and not used in BJ functions.

But for systems that can be copied to maps... does that mean if you use the same boolexp all the time, there is no need to delete it, but just let it exist?

boolexp like strings it stored permanently in some table, and surely cannot be destroyed completely

And() , Or() and Not() return new boolexprs that have to be cleaned.

Also destroying a Boolexpr does remove it even if it was returned by Condition() or Filter() which have caching. Ask grim if you wish to.

here's the explanation of what brought this up originally

I am storing a boolexpr for each one of my objects (this is for the hero part of the object engine), and the boolexpr is the condition to decide whether you should be able to swing your weapon at a particular target or not. For for example you might do


If boolexprs behaved like every other handle, this SHOULD return a unique handle which is stored in that variable. And then when the object is later deleted, this boolexpr must be deleted to prevent a leak.

The problem came when I tried deleting (and cleaning up, i.e. deleting the boolexpr too) any of the heroes using a boolexpr created from this function. It caused EVERY hero using a boolexpr formed from the function to have their boolexpr deleted. (Did not test heroes with different condition functions). That means it always returned false and no one was able to swing their weapon.

So it seems that if you want to produce a unique boolexpr that doesn't get deleted like this, you must do this instead:

Actually I made the engine take the boolexpr you give it and perform that trick on it, so the user doesn't need to care about this. But it's something you must know about if you use boolexprs. I think almost no one actually uses them though.

Oh, another thing, it seems that creating a condition or filter from the same function over and over does not leak (unless you use the Or/And/Not trick).

you taling about some "news" which are not news at lest 1 year...

yes ! but maybe it can be destroyed... but it makes 0 sense !

every time a new ??? i am not sure... i got to test it...

PS And() , Or() and Not() - who need this shit ?!?! i would never use them !

But doesn't this basically mean you don't need to clean these boolexpr's up? So you could just leave them around and it wouldn't leak.

yes it is so ! i never destroy them !

Yes I suppose another way to do it would be to never clean the boolexprs and it shouldn't leak more than 1 copy no matter how many units use that condition. I think I will try it this way and see if it does not cause any issues.

You need to clear them if you use And() , Or() or Not()

Now we only need to think of a good reason to actually use those natives

I kind of expected this, never bothered to test, but I've never used boolexpr in periodic events so I always let them leak.

to make stuff clear:

Shows only one !

have you tested for leaks =) ? (memory)

Well, seeing as you only have a preset number of boolexpr functions and they can be used at any time, it's not really leaking and it's most likely going to be more efficient than constantly creating/destroying unique ones.

>> Doesnt Leak
>> Leaks