Destroying null variables

09-14-2006, 05:58 PM

I was just scripting around when i suddenly needed the GetPlayableMapRect. As usual I never remember the bj_ names of these globals so I thought that I could just convert some gui. Digged a little deeper and found these BJ functions.
I thought it looked strange how it destroyes the BoolExpr which is null. This is completely new to me.

Is it just blizzard fooling around or is there some real reason behind this?

JASS:

function GetUnitsInRectMatching takes rect r, boolexpr filter returns group
    local group g = CreateGroup()
    call GroupEnumUnitsInRect(g, r, filter)
    call DestroyBoolExpr(filter)
    return g
endfunction

function GetUnitsInRectAll takes rect r returns group
    return GetUnitsInRectMatching(r, null)
endfunction

09-14-2006, 06:20 PM	#2
Captain Griffen	It may get passed a boolexpr. That would prevent a leak. I think other BJs use GetUnitsInRectMatching.

09-14-2006, 06:33 PM	#3
Chuckle_Brother	Yup, like: GetUnitsInRectOfPlayer GetUnitsInRectMatching It only passes null since its ALL units, no conditional there. At any rate, I doubt there is an issue with destroying something that is null since it gets done in many maps with GUI.

09-14-2006, 07:56 PM	#4
Vexorian	I would say that accessing null is always a bad idea, also vile had some problems caused by that if I remember correctly.

09-14-2006, 09:34 PM	#5
oNdizZ	Ah, never thought about that other functions were using that aswell. How could accessing null create any problems? And the solution to that would just be to create a dummy boolexpr and use that?

09-14-2006, 09:36 PM

Vexorian

Quote:

How could accessing null create any problems?

Ask blizzard.

Quote:

And the solution to that would just be to create a dummy boolexpr and use that?

Just do not use that function

09-14-2006, 09:44 PM	#7
oNdizZ	Well, since all GroupEnum functions takes a boolexpr the only alternatives i can see right now would be an array or using some global groups and just add the units on creation. For some strange reason, I'm quite against using arrays. Don't ask why, becouse it will probably take some time for me to figure it out.

09-14-2006, 09:49 PM	#8
Vexorian	but you can just use the GroupEnums with null.

09-14-2006, 09:52 PM

Naakaloh

Write your own function or just use the native...

Calling a function with a handle variable that returns null can cause, as far as I know, just the thread to crash, the repercussions however could lead to several other unexpected events.

The GroupEnumUnitsInRect function takes a boolexpr, but giving it a null value for that parameter just means there are no filter conditions for the enumeration.

09-14-2006, 09:59 PM

#10

Vexorian

Notice that most natives are methods so I would say that a null boolexpr on GroupEnumUnitsInRect is safe but using a null group there might be a problem. I don't think many c++ programmers out there would like to add checks for (this!=null) to their public methods...

Quote:

just the thread to crash,

Those are uninitialized values.

09-14-2006, 10:01 PM	#11
oNdizZ	Ah my bad then. I thought you meant that passing null in general might cause some bugs.

09-14-2006, 11:16 PM

#12

Chuckle_Brother

If passing null values were bad wouldn't it be inadvisable also then to not use null on ANY enumerations/functions?

If this were really an issue I think we would have known a long time ago, since I use a null(as do many) on stuff like UnitDamageTarget, for the weapon type, also for setting unit fly heights instantly.

@Vexorian...You sure that wasn't related to retrieving null values in a gamecache? Because that I know can cause thread crashes(almost certainly).

09-14-2006, 11:48 PM

#13

Vexorian

you are not understanding.

DestroyGroup(null) == bad
call GroupEnumUnisInRange(null,x,y,500,bexpr) == bad
call GroupEnumUnisInRange(g,x,y,500,null) == good

It has nothing to do with gamecache
You see? It is bad if the null is the main variable. The GroupEnums surelly have a check for null Boolexprs , but if you for example pass null to DestroyGroup or DestroyBoolExpr , it might be Ok, but it is still lame coding. And there are risks

09-14-2006, 11:53 PM

#14

Naakaloh

Quote:

Calling a function with a handle variable that returns null can cause, as far as I know, just the thread to crash

Quote:

Originally Posted by Vexorian

Those are uninitialized values.

Heh, yeah, that's what I meant; the implication was in the examples you gave later. :/

09-14-2006, 11:54 PM	#15
Chuckle_Brother	Yeah, I didn't mean main variables like that, I meant more within the field of what he is refering to, which would be conditions and support variables. About the GC, from what I heard out of Vile on msn, I took it that his issues were mostly related to the GC, I may be wrong though...which is what I thought you were refering to.