I'm so baffled that this must be easy. What is the proper test to see if a string is null? More to the point, why does the following code bomb out on the conditional test? "foo.txt" => string g; <<< g >>>; // prints '"foo.txt" : (string)' if (g != null) { // evidently crashes here with "[chuck](VM) NullPointerException (during string op)..." <<< "not null" >>>; } else { <<< "is null" >>>; }
On 24 Jun 2009, at 21:12, Robert Poor wrote:
I'm so baffled that this must be easy. What is the proper test to see if a string is null? More to the point, why does the following code bomb out on the conditional test?
"foo.txt" => string g; <<< g >>>; // prints '"foo.txt" : (string)' if (g != null) { // evidently crashes here with "[chuck](VM) NullPointerException (during string op)..." <<< "not null" >>>; } else { <<< "is null" >>>; }
Possibly you have discovered a new type in ChucK :-): One would expect there to be two types: copy-over data types and reference types. And null tests should only be applicable to the latter, as the former do not have explicit references. So if strings were reference types, you should have an @=> there, and get an error on =>. If I change your example to: null => string g; <<< g >>>; // prints '"foo.txt" : (string)' if (g != null) { // evidently crashes here with "[chuck](VM) NullPointerException (during string op)..." <<< "not null" >>>; } else { <<< "is null" >>>; } Then 'chuck' hangs for a while, and then (it or the system) reports "bus error". Hans
If I had to guess (and I should really just look at the code), the
"==" and "!=" operators when applied to strings in ChucK end up doing
a string comparison, NOT a pointer comparison or reference comparison.
In most cases this is what people would want, because they want to be
able to write things like this:
if(x == "hi there") doThatThing();
if(y != "you suck") doTheOtherThing();
This method/function will interrogate the left- and right-hand objects
to determine whether or not the strings are the same. In the case you
gave, Robert, the right-hand object is null, which is why you get the
null pointer exception.
Hans, the bus error that you're seeing is a result of the fact that
you are trying to print out a null value. Your code isn't even getting
to the conditional.
andy
On Wed, Jun 24, 2009 at 12:30 PM, Hans Aberg
On 24 Jun 2009, at 21:12, Robert Poor wrote:
I'm so baffled that this must be easy. What is the proper test to see if a string is null? More to the point, why does the following code bomb out on the conditional test?
"foo.txt" => string g; <<< g >>>; // prints '"foo.txt" : (string)' if (g != null) { // evidently crashes here with "[chuck](VM) NullPointerException (during string op)..." <<< "not null" >>>; } else { <<< "is null" >>>; }
Possibly you have discovered a new type in ChucK :-):
One would expect there to be two types: copy-over data types and reference types. And null tests should only be applicable to the latter, as the former do not have explicit references. So if strings were reference types, you should have an @=> there, and get an error on =>. If I change your example to: null => string g; <<< g >>>; // prints '"foo.txt" : (string)' if (g != null) { // evidently crashes here with "[chuck](VM) NullPointerException (during string op)..." <<< "not null" >>>; } else { <<< "is null" >>>; }
Then 'chuck' hangs for a while, and then (it or the system) reports "bus error".
Hans
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On 24 Jun 2009, at 21:41, Andrew Turley wrote:
Hans, the bus error that you're seeing is a result of the fact that you are trying to print out a null value. Your code isn't even getting to the conditional.
Yes, I changed it to: null @=> string g; // Or: => <<< "g = ", g, "." >>>; Then it does not get to the ".". If 'chuck' wants to make pointers transparent, then this is a flaw (if not a bug).
If I had to guess (and I should really just look at the code), the "==" and "!=" operators when applied to strings in ChucK end up doing a string comparison, NOT a pointer comparison or reference comparison.
This is another problem with the ChucK model of attempting to largely hide away pointers. Then perhaps 'chuck' checks the pointers for reference types without equality, but for the data when available. That is indeed confusing. Hans
participants (3)
-
Andrew Turley
-
Hans Aberg
-
Robert Poor