dereferencing null

[Jonathan M Davis]

On Sunday, March 04, 2012 21:31:21 Chad J wrote:
> On 03/03/2012 02:06 PM, Walter Bright wrote:
> > On 3/3/2012 2:13 AM, bearophile wrote:
> >> Walter:
> >>> Adding in software checks for null pointers will dramatically slow
> >>> things
> >>> down.
> >> 
> >> Define this use of "dramatically" in a more quantitative and objective
> >> way,
> >> please. Is Java "dramatically" slower than C++/D here?
> > 
> > You can try it for yourself. Take some OOP code of yours, and insert a
> > null check in front of every dereference of the class handle.
> 
> I have a hard time buying this as a valid reason to avoid inserting such
> checks.  I do think they should be optional, but they should be
> available, if not default, with optimizations for signal handlers and
> such taken in the cases where they apply.
> 
> Even if it slows my code down 4x, it'll be a huge win for me to avoid
> this stuff.  Because you know what pisses me off a helluva lot more than
> slightly slower code?  Spending hours trying to figure out what made my
> program say "Segmentation fault".  That's what.

Really? I rarely run into segfaults, and when I do, it's easy enough to enable 
core dumps, rerun the program, and then get an actual stack trace (along with 
the whole state of the program for that matter). Yes, upon occasion, it would 
be useful - especially if you're talking about a large program where you can't 
simply rerun it with core dumps enabled and quickly reproduce the problem, but 
in my experience, the reality of the matter is that it's a very rare 
occurence. And if it really is something that keeps causing you problems, on 
Linux at least, it's very easy to enable a signal handler to get you a stack 
trace.

So, I can see your complaint, but I find that it's rarely justified in practice.

- Jonathan M Davis