(bool) gameObject vs gameObject == null?

What is the difference between:

Code (CSharp):

1. var go = GameObject.Find("random name");
2. if (go) go.SetActive(false);

And

Code (CSharp):

1. var go = GameObject.Find("random name");
2. if (go != null) go.SetActive(false);

 

gameObject is a reference to the GameObject of whatever your working with (Transform, MonoBehaviour). Saying

Code (CSharp):

1. if(someComponent.gameObject != null) {

is seeing if the referenced GameObject exists. Although, if the gameObject doesn't exist, I would imagine the 'someComponent' component stated above would throw a Null exception before anything else.

 

null translates to false, so essentially they are the same. I hadn't seen it used that way to test for a null before. It might work with GameObject because of a return or something, but I think I would just test for null to be on the safe side, unless someone knows if that would always be safe to use for any object.

 

Sorry if I wasn't clear. I meant what is the difference between:

Code (CSharp):

1. var go = GameObject.Find("random name");
2. if (go) go.SetActive(false);

And

Code (CSharp):

1. var go = GameObject.Find("random name");
2. if (go != null) go.SetActive(false);

 

Is this about the Unity overloads? In Unity, "if(go==null)" doesn't actually check whether it's null. If "go" isn't null, the system also checks whether the gameObject it points to has been destroyed, which also counts as null.

I think there may have once been a difference, in Unity, between "if(go)" and "if(go==null)" (the first didn't use the good Unity trick?) But I did a little testing and couldn't find a difference. They did discuss keeping/changing it recently.

 

They are the same. The implicit bool operator on UnityEngine.Object is written to check what @Owen-Reynolds mentioned.

In my opinion, it's very handy. I like to add that to my own stuff (bool meaning class ref not null, I mean).

Here, if you search for "implicit operator bool", you can see: https://github.com/MattRix/UnityDecompiled/blob/master/UnityEngine/UnityEngine/Object.cs

 

This is correct. To expand on it, C# will try to convert any expression in an if statement to boolean. In this case, it's given an implicit conversion from Object (from which GameObject, MonoBehaviour, etc all inherit from) to boolean. In particular, this specific line. It's just comparing to null using the CompareBaseObjects method.

If you look up slightly you'll see that the Equals method also uses this CompareBaseObjects method to do its comparison. I'm sure there may be some subtle differences, but more or less both if statements are doing the same exact thing. They'll be true if the reference is not null and references a valid Unity object, otherwise it'll be false.

Which one to use? I'd use the more explicit one. It's a few extra characters and is more clear.

There's one more thing to understand here: even though the references are not null, references to Unity objects that have been destroyed will appear to be null. If you destroy a GameObject and then compare a reference you had to it before destroying with null, it will appear to be null. It's not though, and this can cause some confusion. If you store a reference to a MonoBehaviour on an object then destroy that object, you can still call methods on that "dead" behaviour and it can appear to continue working. Just know that sometimes you can have "zombie" objects that when compared with null will appear to be null, but some methods on them will still work with no errors.

 

The trouble is, this isn't a c# behavior, so it's restricted to monoBehaviour. That, to me, would be a bad habit to get into. In general, when I see that used, I assume it's an actual bool, so I think it would also cause some confusion for other people reading the code.
https://designagame.eu/2014/08/a-note-of-the-wild-use-of-ifobject-in-unitys-c-code/

 

Destroyed objects equating to null is what I have a problem with. Because you can destroy game objects indirectly way too easily. Basically another level of indirection that just makes it more difficult to write proper code around. It's too easy to just destroy a GameObject with multiple components or children with components, leaving references in other areas of the code invalid. You really need a pattern where you explicitly assign a GameObject to a class, and it's only through that class that you can destroy it, along with that class knowing about any other components on the GameObject and children.

Which means using stuff like GameObject.Find is out of the question for the most part, outside of cases like networked games where you don't have a choice.

 

You can code your own (generic C#) class to use an implicit bool operator for the same purpose. That's what they did.

Edit:
After I actually read the post, I see that's said there, too. So not "automatic" but also part of the language, and not just Unity..

Read the first bit of the link you posted, and it goes on to say in the first comment something I would have said, too. In C, if(pointer) means not null. They also have if(1) or if(someInt), which I miss, but that is unrelated, just babbling lol. Related, though, as it was basically if !Zero