On 3/1/2012 8:51 PM, Jonathan M Davis wrote:
> It's defined. The operating system protects you.

Not exactly. It's a feature of the hardware. You get this for free, and your code runs at full speed.

Adding in software checks for null pointers will dramatically slow things down.

"Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:jxloisomieykanavmmlj@forum.dlang.org...
> On Friday, 2 March 2012 at 10:01:32 UTC, Daniel Murphy wrote:
>> "Peter Alexander" <peter.alexander.au@gmail.com> wrote in message news:vicaibqyaerogseqsjbe@forum.dlang.org...
>>>>
>>>> It's defined. The operating system protects you. You get a segfault on
>>>> *nix and
>>>> an access violation on Windows.
>>>
>>> False.
>>>
>>> [snip]
>>>
>>> You only get an error if there is a memory access involved (vtable, member data etc.)
>>>
>>
>> It _is_ defined, you get an access violation whenever there's a
>> dereference.
>> Yes, you can call some types of member functions without any
>> dereferences,
>> but this is alse well defined and sometimes quite useful.
>
> Ok, if it is defined, then please tell me what the defined behaviour of my code snippet is.

Assertion failure in debug mode, prints the message in release mode. (I think)

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?

Bye,
bearophile

On Saturday, 3 March 2012 at 10:13:34 UTC, 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?
>
> Bye,
> bearophile

It's not a fair comparison, because the Java JIT will optimize the null checks away...

Signal handlers might be the answer though, if the same behavior can be guaranteed on all major platforms...

On 3 March 2012 23:13, bearophile <bearophileHUGS@lycos.com> 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?
>
> Bye,
> bearophile

Not to be too cheeky here, but since its done in hardware, and therefore no software checks are done, I'm going to say that it is infinitely slower. Since even 1 extra instruction is infinitely more than the current 0.

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.

Le 03/03/2012 20:06, Walter Bright a écrit :
> 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.

Why would you want to check every time ? You program will get a signal from the system if it try to deference a null pointer, so thing can be done in the signal handler, and no cost is involved.

On 03/03/2012 09:00 PM, deadalnix wrote:
> Le 03/03/2012 20:06, Walter Bright a écrit :
>> 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.
>
> Why would you want to check every time ? You program will get a signal
> from the system if it try to deference a null pointer, so thing can be
> done in the signal handler, and no cost is involved.

The signal will likely be the same for the following two code snippets:

void main(){
    Object o;
    o.toString();
}

void main(){
    *cast(int*)0xDEADBEEF = 1337;
}


How to detect whether or not the access violation was actually caused by a null pointer?

I would recommend doing what Microsoft does in this case, use SEH
(Structured exception handling) on windows i.e. use OS facilities
to trap and convert hardware exceptions into software exceptions.

See the /EHa flag in the Microsoft C++ compiler.

I hope Linux has something similar, then we are all set!

ref:
http://msdn.microsoft.com/en-us/library/1deeycx5(v=vs.80).aspx

On Saturday, 3 March 2012 at 02:51:41 UTC, Walter Bright wrote:
> On 3/1/2012 8:51 PM, Jonathan M Davis wrote:
>> It's defined. The operating system protects you.
>
> Not exactly. It's a feature of the hardware. You get this for free, and your code runs at full speed.
>
> Adding in software checks for null pointers will dramatically slow things down.

On 3/3/2012 12:29 PM, Sandeep Datta wrote:
> I would recommend doing what Microsoft does in this case, use SEH
> (Structured exception handling) on windows i.e. use OS facilities
> to trap and convert hardware exceptions into software exceptions.

D for Windows already does that.

It's been there for 10 years, and turns out to be a solution looking for a problem.