| |||||||||||||
RE: nullable pointersRE: nullable pointersPosted Mar 31, 2011 13:29 UTC (Thu) by HelloWorld (guest, #56129)In reply to: RE: nullable pointers by neilbrown Parent article: GCC 4.6.0 released
> I'm having trouble understanding the argument against nullable pointers.
And I'm having trouble understanding why one would want a nullable pointer. I have yet to see a use case where they provide a substantial benefit. What I do see is that programs crash due to null pointer exceptions all the time.
(Log in to post comments)
RE: nullable pointers Posted Apr 1, 2011 4:04 UTC (Fri) by neilbrown (subscriber, #359) [Link]
> What I do see is that programs crash due to null pointer exceptions all the time.
What do you think those programs would do there were no null pointers?
One cannot know for sure, but I am certain that simply disallowing NULL pointers will not make incorrect programs correct except in a tiny minority of cases (if at all).
The thing that would have made the talk much more interested would be a description of what could have been done at the time which could have made a difference.... but I don't think there is anything.
RE: nullable pointers Posted Apr 1, 2011 4:19 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> There are various possibilities: throw an 'invalid type' error instead, enter an infinite loop, produce an incorrect answer, kill your cat....
You forgot the one that matters: they may fail to compile. In languages like ML, a variable can't be "null". The closest thing to null that ML has is the Option datatype, and if you try to pass an expression of type t Option to a function expecting an argument of type t, your program won't compile.
RE: nullable pointers Posted Apr 1, 2011 8:12 UTC (Fri) by neilbrown (subscriber, #359) [Link]
ahh... I get it now.
What you are saying (I think) is that not only should the language provide a 'non-nullable' pointer type (which the compiler assures will never be NULL), but that where a nullable pointer is used, the language should require that there be an explicit test for NULL before dereferencing the pointer or assigning it to a non-nullable pointer.
That makes sense.
So you will never get a NULL dereference, and the compiler/runtime doesn't have to do implicit tests because tests are required to be explicit.
RE: nullable pointers Posted Apr 1, 2011 12:46 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> What you are saying (I think) is that not only should the language provide a 'non-nullable' pointer type (which the compiler assures will never be NULL), but that where a nullable pointer is used, the language should require that there be an explicit test for NULL before dereferencing the pointer or assigning it to a non-nullable pointer.
Yes, this is exactly what I meant.
RE: nullable pointers Posted Apr 1, 2011 8:48 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> You forgot the one that matters: they may fail to compile.
Yup. You learn Haskell and/or ML (and/or ...) and the case against null pointers becomes so obvious you don't even know how to explain it.
RE: nullable pointers Posted Apr 1, 2011 9:12 UTC (Fri) by paulj (subscriber, #341) [Link]
So in Haskell you never have to do things like have a separate case for an empty list?
If you specifically mean SEGVs, well that's very easy to explain: Haskell and functional languages generally do not have pointers.
RE: nullable pointers Posted Apr 1, 2011 21:01 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
You still have to case on the empty list (e.g., you can't get the first value from it, so if you need it, you need to do /something/ different for the empty list unless you want exceptions about incomplete pattern matchings). An example:
safeHead :: [a] -> Maybe a
When calling safeHead, the caller must* check to see if a value was actually returned before using it. This can be done with fromMaybe:
fromMaybe sensibleDefault $ safeHead someList
* The caller can just use fromJust which raises an exception on a Nothing value, but that's the caller's burden at that point.
|
|||||||||||||