Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next Mainstream Programming Language: A Game Developer's Perspective". Using Epic's Unreal Engine 3 as an example, he goes through several limiting and costly issues with C++ and other current mainstream languages, then moves on to what he wants to do before closing with features he thinks the next mainstream language should have. If you aren't so interested in what he says about language features, it's interesting enough reading the insights he gives to the Unreal Engine.

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:ds6bbn$1tp3$1@digitaldaemon.com...
> Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next Mainstream Programming Language: A Game Developer's Perspective". Using Epic's Unreal Engine 3 as an example, he goes through several limiting and costly issues with C++ and other current mainstream languages, then moves on to what he wants to do before closing with features he thinks the next mainstream language should have. If you aren't so interested in what he says about language features, it's interesting enough reading the insights he gives to the Unreal Engine.
>
> http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
>

Interesting how he comments time and time again how much he'd like null pointer dereferencing to be checked.. funny, last time I brought that up, Walter shot it down, since after all, access violations are more than enough!  Right guys?  Right?

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:ds6oia$26g5$1@digitaldaemon.com...
> Interesting how he comments time and time again how much he'd like null pointer dereferencing to be checked.. funny, last time I brought that up, Walter shot it down, since after all, access violations are more than enough!  Right guys?  Right?

I looked for his email address, but couldn't find it. I'd ask him how checking for null pointers in software before dereferencing would result in fewer bugs than having the hardware check it automatically. Because it won't:

    assert(p != null);
    p[3] = 2;

is not one whit more robust than:

    p[3] = 2;

The bug is not dereferencing a null pointer, it is why that pointer is null in the first place. Often, pointers are null because:

1) uninitialized data (he mentions that this is a big source of problems)

2) often, functions return NULL when they fail rather than throw an exception (like malloc() does)

On Mon, 6 Feb 2006 01:00:03 -0500, Jarrett Billingsley wrote:

> "Mike Parker" <aldacron71@yahoo.com> wrote in message news:ds6bbn$1tp3$1@digitaldaemon.com...
>> Tim Sweeney of Epic Games recently gave a talk at POPL'06 titled "The Next Mainstream Programming Language: A Game Developer's Perspective". Using Epic's Unreal Engine 3 as an example, he goes through several limiting and costly issues with C++ and other current mainstream languages, then moves on to what he wants to do before closing with features he thinks the next mainstream language should have. If you aren't so interested in what he says about language features, it's interesting enough reading the insights he gives to the Unreal Engine.
>>
>> http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
>>
> 
> Interesting how he comments time and time again how much he'd like null pointer dereferencing to be checked.. funny, last time I brought that up, Walter shot it down, since after all, access violations are more than enough!  Right guys?  Right?

I understood that this argument went something like ...

One can have null pointers checked by the compiler, by software at run time, or by hardware at run time. The first is not always going to work (to find all cases), the second is (can be) a performance hit and is susceptible to compiler bugs, and the third is the fastest and always works (on modern CPU's anyway).

So with the current D, one does get null pointer dereference checking; its just that it looks like an access violation instead. So maybe we can plead, cajole, whatever to make Walter give us a more meaningful message when an access violation is the result of a NULL pointer (file name and line number would be a bloody big help too).

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
6/02/2006 5:55:26 PM

Jarrett Billingsley wrote:
> Interesting how he comments time and time again how much he'd like null pointer dereferencing to be checked.. funny, last time I brought that up, Walter shot it down, since after all, access violations are more than enough!  Right guys?  Right? 
> 

Cyclone is a language (based on C) that introduced array bounds checks and fat pointers:
http://www.research.att.com/projects/cyclone/online-manual/main-screen002.html#toc3

When I took a OSs course with Michael Hicks' (one of the people behind Cyclone) he urged students to use Cyclone in order to make their life easier. Somehow it never caught on. I had no problems finishing any of the projects in plain C, but I always wondered if Cyclone would have made things easier.

The bug that caused me the most grief was not a pointer issue. I was calling a WriteBlock() function to READ a page from the drive(that didn't work, DUH). The bug was caused by a copy pasting error. The experience has taught me that NULL pointers are quite manageable.

Also, I don't know that Sweeny's desire for dereference checking is justified. I would like to see some hard numbers to be convinced. Finally, I believe this is best left to tools like LINT.

"Derek Parnell" <derek@psych.ward> wrote in message news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg@40tude.net...
> So with the current D, one does get null pointer dereference checking; its
> just that it looks like an access violation instead. So maybe we can
> plead,
> cajole, whatever to make Walter give us a more meaningful message when an
> access violation is the result of a NULL pointer (file name and line
> number
> would be a bloody big help too).

Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a call stack trace.

It works even better than just a null check, it checks for any pointer value that falls outside of address space allocated to the process.

On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright wrote:

> 
> Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a call stack trace.

I just *knew* you were going to say that <G>

For those that need to know about this in Windows environments...

You can get the Microsoft debugger from http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.6.03.5.exe

And once you install it, compile your D program with the -g switch.

To get it running under the debugger ...

  windbg mytest.exe

then press F5 till it stops running ... then look at the register values and the assembly instruction to see what might be wrong. Easy eh? So you thought you only had to learn D --- silly you. A good knowledge of assembler is useful when using the debugger properly.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
6/02/2006 8:12:33 PM

On Mon, 06 Feb 2006 11:16:36 +0200, Derek Parnell <derek@psych.ward> wrote:

> On Sun, 5 Feb 2006 23:56:37 -0800, Walter Bright wrote:
>
>>
>> Compile with -g, and run it under the debugger. When the access violation
>> happens, the debugger gives you the location of the fault, as well as a call
>> stack trace.
>
> I just *knew* you were going to say that <G>
>
> For those that need to know about this in Windows environments...
>
> You can get the Microsoft debugger from
> http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.6.03.5.exe
>
> And once you install it, compile your D program with the -g switch.
>
> To get it running under the debugger ...
>
>   windbg mytest.exe
>
> then press F5 till it stops running ... then look at the register values
> and the assembly instruction to see what might be wrong. Easy eh? So you
> thought you only had to learn D --- silly you. A good knowledge of
> assembler is useful when using the debugger properly.
>


The standart answer Walter gives to that is "Microsoft's newer windbg's
seem to have dropped support for codeview debug info. But the one that comes
on the Digital Mars CD *does* work."
Anyway you can try this one:
http://www.cs.nmt.edu/~cs221/jbpub/Detmer/Software/
Just download the exe & the dll files.
Of course, that version does NOT work with obj files compiled with current dmc
so if you are trying to bridge C or even worse C++ code with D you are out of
luck but see above.
Another advice I receive is to use GDB but I really prefer to postpone my serious
usage of D that to come near that beast.
Cheers,
Todor

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds70qm$2d28$1@digitaldaemon.com...
> Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a call stack trace.

Yeah, that'd be fantastic if the break didn't always happen in the middle of NTDLL.  And if the stack trace actually worked properly, which it doesn't, making it nearly impossible to find where the AV occurred.  (VS6)

> The bug is not dereferencing a null pointer, it is why that pointer is
> null
> in the first place. Often, pointers are null because:
>
> 1) uninitialized data (he mentions that this is a big source of problems)
>
> 2) often, functions return NULL when they fail rather than throw an
> exception (like malloc() does)

In D, neither of these really apply.  All variables are initialized (including references to NULL, hint hint), and when functions fail, they throw an exception.  So it's very easy to get a null pointer - just forget to initialize a reference, and then try to access one of its members.  Or perhaps delete a reference (which, again, sets it to null) and try to access it.

Fun fact: I've yet to have an access violation in D that _wasn't_ because of a null reference.  And I've had quite a few.

> Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a
call
> stack trace.


Ummmm... What debugger, the 15 yeard old windbg that comes on the CD that you have to purchase ?  Debugging D has become extremely painful , all these great new age techniques to speed productivity, then it takes 5 - 6 hours to setup an assembly level debugger , then a few years to learn assembly , and your ready to use D!

The other access voilations throw line number and file, why this inconsitency ?


"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds70qm$2d28$1@digitaldaemon.com...
>
> "Derek Parnell" <derek@psych.ward> wrote in message news:biyilad45wk1$.1iwp3vmzjd3x9$.dlg@40tude.net...
> > So with the current D, one does get null pointer dereference checking;
its
> > just that it looks like an access violation instead. So maybe we can
> > plead,
> > cajole, whatever to make Walter give us a more meaningful message when
an
> > access violation is the result of a NULL pointer (file name and line
> > number
> > would be a bloody big help too).
>
> Compile with -g, and run it under the debugger. When the access violation happens, the debugger gives you the location of the fault, as well as a
call
> stack trace.
>
> It works even better than just a null check, it checks for any pointer
value
> that falls outside of address space allocated to the process.
>
>