Null pointer reference...is this a bug?

[monkey0506]

I've just noticed that you can't compare a null String to anything other than null. Trying to compare them to other Strings (null or non-null; left or right side of the comparison operands) generates a null pointer reference error. I'm not really sure if this is a bug or just me being stupid...

Anyway...if it's at all possible it would be nice if we could compare null Strings to other Strings...

[Pumaman]

This was a deliberate decision, however I'm struggling to remember the reason why. Does anyone else have any feelings on this?

[Kweepa]

Hmm,
I don't see any down side to allowing the comparison.
(null != non_null) == false
(null == null) == true
I'm surprised that Strings can be null at all though. It seems unnecessarily dangerous. Shouldn't they "default construct" to an empty string?

[monkey0506]

Actually Steve...(null != non_null) would evaluate to true...o.0

But I would find it nice if Strings defaulted to "" instead of null. I've actually become slightly accustomed to the way they are now, though it would be nicely easy to adjust if this behaviour changed.

However it would be useful for other pointer types as well (IMO).

[Alynn]

To piggyback off of monkey... I find the same to be true with overlays. Mostly to do with the Valid statment. It seems silly to have to initilize the overlay at all if it is null then the Valid should return false. This is mostly an issue when I have an overlay pointer to keep track of background speach.

It just seems to be silly to have to have an extra if check when Valid should take care of both.

[SSH]

In most modules I have written, I usually set pointers to null after I have deleted the Dynamic Sprite or Overlay ro whatever, so that I only have to do one check. But of course, you can't path a null pointer...

[RickJ]

I think I asked about this before and the concensus was that we should be that we should be pureists in out programming.   I was unable to persuade anyone that "anything" could never be equal to a non-existent something (i.e. NULL) and that a comparisom operation of the two should return the appropiate status value rather than a run-time error. 

In my opinion this only leads to unecessary and redundant code, where you first have to check for NULL before you do anything else; When you could have just checked for whatever you were interested in. 

I also think it would be better if  NULL pointers could pass through the .AsFunctions()  without generating a runtime error.   For example Pointer.AsButton() returns NULL if Pointer is not pointing to a button; so if Pointer is NULL then it can't very well be a button could it? 

Just my two cents.  I would vote to NULL pointers a bit more user friendly.  I'm too old and lazy to type in extra stuff. 

[Scorpiorus]

I would not suggest to just allow to reference a null-pointers as a default rule but generate a run-time error as the engine does it now, as it would make it easier to spot logic mistakes in the massive source code where, for example, an instance being used is supposed to be created when in reality it's not, making wrong decisions in respective if-then statements. Better a run-time error than a code that "seems" to work I believe.

But in particular situations (with certain types and thier functions and operators) do allow null-valued pointers to be used as parameters in those functions/operators to reduce redundant code, where practical.

As for String, if I recall correctly, its comparison operators are specialized to perform a content comparison which is vital for strings (unlike for example for GUIs where different values of pointers practically mean different GUIs they are pointing to). Enchancing those operators to do additional comparisons seems ok. One thing though, is how should we interpret an empty string? Unlike basic types strings can be set to, so to say, "nothing" state. Formerly, a zero-sized string indicated that state, but now with the introduction of OO-scripting we also have a null state which then becomes conceptually equal to a zero-sized string (""):

String S = null; // default initialization
String Z = ""; // initialized with a string (although empty but still a string instance)

if (S == Z) {...} // should it be true or false or run-time error?


Regarding initialization of all Strings to "" is a workaround (currently I always do this when creating them, partucularly Strings in structs) but this approach would require to initialize all String pointers, including arrays of Strings (the question of allocating memory; performance/memory use: what minimal buffer size allocated per string?). Furthermore, even if they were initialized we could still do "someString = null;" later and someString will generate a run-time error if compared afterwards. So, assigning to null should then also be disallowed in that case.