> What does null do better than this simple class hierarchy?
I'm well aware that you can build a nullable pointer out of a non-nullable one. C++ has boost::optional which is kind of a nullable object, templated in a similar way. However, that technique is less efficient and more cumbersome than just using a regular pointer.
So far, you haven't presented any actual evidence that non-nullable pointers are helpful to programmers. Your whole argument depends on the idea that nullable pointers are somehow this huge source of bugs. But in my 10 years of C++ (and some Java) I haven't found this to be the case. I am much more worried about race conditions, implicit narrowing of numerics, and code that handles error conditions poorly than I ever will be about NULL pointers.
It's like trying to sell me insurance against stampeding elephants. I know that elephants can kill, but honestly, I'm not that worried about them. I have other things to worry about.
C++ has non-nullable pointers in the form of references. However, despite this fact, programmers continue to use pointers. Apparently either the advantages of a non-nullable pointer aren't that great, or the weight of legacy code is too heavy. I guess you're free to interpret it however you like.
When you look at static code analysis tools that people run in the real world, they tend to look for things like race conditions, uninitialized memory uses, double frees, and so on. You could imagine annotating your pointers with something like "attribute __nonnull", and using your tool to look for violations of that, but in practice, nobody bothers to do it.
Now is any big Java project using this stuff? If not, why not? These are the kind of questions we should be asking.
Please don't misinterpret what I'm saying. I'm not necessarily against non-nullable pointers, I'm just saying that the evidence presented here has not been persuasive.
Posted Mar 29, 2011 10:52 UTC (Tue) by nix (subscriber, #2304)
[Link]
I've been religiously doing nonnull attribute decorations in the code I write for more than ten years. Violations are hardly ever detected.
However, I get null pointer errors on a fairly regular basis, because GCC's nonnull attribute can only warn you if it can be sure a pointer is NULL, and if it's received from somewhere else it can't tell that. Whole-program compilation will help, but a lot of code is in shared libraries, and there, you have no recourse.
But if the *actual type* of the pointer was different (so the compiler could distinguish 'non-null pointer to object' and 'nullable pointer to object' even for external symbols) this error would largely disappear (as it does in C++ with references). However, this would require changing the C linkage model, and probably mangling names. Ain't gonna happen.
GCC 4.6.0 released
Posted Mar 30, 2011 7:13 UTC (Wed) by jrn (subscriber, #64214)
[Link]
Sounds like a job for sparse.
GCC 4.6.0 released
Posted Apr 1, 2011 17:51 UTC (Fri) by nix (subscriber, #2304)
[Link]
Yeah, agreed, and if the system I'd been working on then hadn't been a horrible preprocessor-mangled nightmare (Pro*C, and if you have experience with it, my condolences) so sparse would have drowned the real warnings in all the screaming about the hideous wrecked code the preprocessor inserted.
GCC 4.6.0 released
Posted Mar 29, 2011 13:16 UTC (Tue) by HelloWorld (guest, #56129)
[Link]
> However, that technique is less efficient and more cumbersome than just using a regular pointer.
If these are an actual problem in your code, you're probably overusing "optional" elements anyway. I almost never need them.
> Your whole argument depends on the idea that nullable pointers are somehow this huge source of bugs. But in my 10 years of C++ (and some Java) I haven't found this to be the case.
I see programs crashing due to null pointer dereferencing almost every day, but maybe that's just me. And anyway, the bad effects of the null pointer mistake aren't limited to just bugs. As I said earlier, primitive types wouldn't have been necessary if null didn't exist. And I've seen people put null checks in all kinds of random places so if a null value shows up where it shouldn't have, the program won't even crash and allow you to debug it.
Finally, what really bugs me about null is that it's so utterly arbitrary. There's no real reason for having this magical thing that is a value of every type, but supports almost none of the operations allowed for that type.
> C++ has non-nullable pointers in the form of references. However, despite this fact, programmers continue to use pointers.
That's because you can't make a C++ reference refer to another object once you've initialized it. It's more like a final reference in Java than like an ordinary reference.
> Please don't misinterpret what I'm saying. I'm not necessarily against non-nullable pointers, I'm just saying that the evidence presented here has not been persuasive.
Well, our experiences regarding null pointers seem to differ. I don't think there's much more left to say.