www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal - Check for null reference in debug build

reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
We already have array bounds checking in the debug build, accomplished 
through a sort of implicit assert, such that

int x = array[index];

Becomes

assert(index >= 0 && index < array.length); int x = array[index];

This is to prevent (mostly) the irritating off-by-one errors so common in 
array handling but which cause a vague memory access violation in 
nonprotected languages such as C++.  This is a very helpful debugging 
feature.

I think that a logical extension of this would be to check for null 
references in debug builds as well.  How many times has trying to call a 
method of a null reference bitten you?  I propose that this:

obj.doSomething();

Would be implicitly compiled as

assert(obj !is null); obj.doSomething();

This would severly cut down on the amount of "find the segfault" scavenger 
hunts that are the bane of any programmer's existence.

Since this might severely impact performance, it might even be implemented 
as a separate compiler switch which could only be used in conjunction with 
the -debug switch.  Then you could turn it on if you get a segfault and see 
if it's a null reference that's causing it.

I'm really tired of stepping through code to find segfaults, and I think 
this would almost entirely eliminate segfaults in D except when dealing with 
pointers. 
Oct 20 2005
next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
Interesting.  I see how it would cut down on segfaults, and I do agree that 
the find the segfault game is rather borring.
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dj8r60$30s1$1 digitaldaemon.com...
 We already have array bounds checking in the debug build, accomplished 
 through a sort of implicit assert, such that

 int x = array[index];

 Becomes

 assert(index >= 0 && index < array.length); int x = array[index];

 This is to prevent (mostly) the irritating off-by-one errors so common in 
 array handling but which cause a vague memory access violation in 
 nonprotected languages such as C++.  This is a very helpful debugging 
 feature.

 I think that a logical extension of this would be to check for null 
 references in debug builds as well.  How many times has trying to call a 
 method of a null reference bitten you?  I propose that this:

 obj.doSomething();

 Would be implicitly compiled as

 assert(obj !is null); obj.doSomething();

 This would severly cut down on the amount of "find the segfault" scavenger 
 hunts that are the bane of any programmer's existence.

 Since this might severely impact performance, it might even be implemented 
 as a separate compiler switch which could only be used in conjunction with 
 the -debug switch.  Then you could turn it on if you get a segfault and 
 see if it's a null reference that's causing it.

 I'm really tired of stepping through code to find segfaults, and I think 
 this would almost entirely eliminate segfaults in D except when dealing 
 with pointers.
 

Oct 20 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 I'm really tired of stepping through code to find segfaults, and I think 
 this would almost entirely eliminate segfaults in D except when dealing 
 with pointers.

I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?
Oct 20 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Ben Hinkle wrote:
I'm really tired of stepping through code to find segfaults, and I think 
this would almost entirely eliminate segfaults in D except when dealing 
with pointers.

I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?

be both useful and newbie-friendly. Ok, gdb might be very good, but it's hard to use. Besides you need to apply a patch to use it. This is not a real problem, but someone has to create new patches for the future versions of gdb.
Oct 20 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <dj919j$5e0$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
Do we really have good debuggers for Linux? I think this feature would 
be both useful and newbie-friendly. Ok, gdb might be very good, but it's 
hard to use. Besides you need to apply a patch to use it. This is not a 
real problem, but someone has to create new patches for the future 
versions of gdb.

Emacs integrated gdb debugging works pretty well IMO. If you want an IDE front-end however, I always thought KDevelop looked pretty nice: http://www.kdevelop.org/ Sean
Oct 20 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message 
news:dj919j$5e0$1 digitaldaemon.com...
 Ben Hinkle wrote:
I'm really tired of stepping through code to find segfaults, and I think 
this would almost entirely eliminate segfaults in D except when dealing 
with pointers.

I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty sure windbg also breaks. Is the reason for wanting an assert exception to get the file and line number without having to start a debugger?

both useful and newbie-friendly. Ok, gdb might be very good, but it's hard to use. Besides you need to apply a patch to use it. This is not a real problem, but someone has to create new patches for the future versions of gdb.

I use gdb without any patches. I know there's some patch to recognize some D-specific data types but I get along ok without it so I've never tried it. Certainly catching segv's doesn't need a patch.
Oct 20 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:dj8tdj$212$1 digitaldaemon.com...
 I'm able to get both Visual Studio and gdb to break at seg-v's. I'm pretty 
 sure windbg also breaks. Is the reason for wanting an assert exception to 
 get the file and line number without having to start a debugger?

Mostly, yes. It's such a common mistake to try to access a null reference that it should be checked for by the debug build. That, and we've already done away with the need to use the debugger to find segfaults caused by invalid array indices; why not take it the rest of the way?
Oct 20 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:dj95ji$964$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message 
 news:dj8tdj$212$1 digitaldaemon.com...
 I'm able to get both Visual Studio and gdb to break at seg-v's. I'm 
 pretty sure windbg also breaks. Is the reason for wanting an assert 
 exception to get the file and line number without having to start a 
 debugger?

Mostly, yes. It's such a common mistake to try to access a null reference that it should be checked for by the debug build. That, and we've already done away with the need to use the debugger to find segfaults caused by invalid array indices; why not take it the rest of the way?

Array bounds errors are not caught by the OS. Code silently continues when you index one past an array but trying to access null generates an immediate segv. So adding code to check for array bounds errors is needed because there is no OS support for it.
Oct 20 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Ben Hinkle wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:dj95ji$964$1 digitaldaemon.com...
 
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:dj8tdj$212$1 digitaldaemon.com...

I'm able to get both Visual Studio and gdb to break at seg-v's. I'm 
pretty sure windbg also breaks. Is the reason for wanting an assert 
exception to get the file and line number without having to start a 
debugger?

Mostly, yes. It's such a common mistake to try to access a null reference that it should be checked for by the debug build. That, and we've already done away with the need to use the debugger to find segfaults caused by invalid array indices; why not take it the rest of the way?

Array bounds errors are not caught by the OS. Code silently continues when you index one past an array but trying to access null generates an immediate segv. So adding code to check for array bounds errors is needed because there is no OS support for it.

does the D specification say that all D implementations should generate code that supports segfaults. I mean if you use an old OS like Windows 9x where memory manager only has a part-time job, the OS may not halt on every segfault.
Oct 20 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message
news:dj98ii$bql$1 digitaldaemon.com...
 Ben Hinkle wrote:
 Array bounds errors are not caught by the OS. Code silently continues


 you index one past an array but trying to access null generates an


 segv. So adding code to check for array bounds errors is needed because
 there is no OS support for it.


It's not quite true, seg faults are generated by the hardware, not the OS. I do not know of any 32 bit system that doesn't operated in 'protected mode' where seg faults happen in hardware, and is supported by the OS. I agree with you that your proposal would be very useful for a real mode operating system like DOS where there are no hardware seg faults or OS support for them, but DOS is dead and 16 bit systems are not supported by D.
 OTOH
 does the D specification say that all D implementations should generate
 code that supports segfaults. I mean if you use an old OS like Windows
 9x where memory manager only has a part-time job, the OS may not halt on
 every segfault.

If you're running a 32 bit app under Win9x, you *will* get seg faults if you dereference NULL, 100% of the time.
Oct 25 2005
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Walter Bright wrote:
OTOH
does the D specification say that all D implementations should generate
code that supports segfaults. I mean if you use an old OS like Windows
9x where memory manager only has a part-time job, the OS may not halt on
every segfault.

If you're running a 32 bit app under Win9x, you *will* get seg faults if you dereference NULL, 100% of the time.

Ok, Win9x does support segfaults in a way. Still I don't find that information very helpful since it's so easy to hang up the whole system by doing some tiny errors. Several years ago I had to stop using Windows 98 since it didn't always tell me (at least immediately) I was running some buggy code (illegal memory pointers). Linux does a lot better job in memory handling.
Oct 25 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message
news:djm2p0$smq$1 digitaldaemon.com...
 Ok, Win9x does support segfaults in a way. Still I don't find that
 information very helpful since it's so easy to hang up the whole system
 by doing some tiny errors. Several years ago I had to stop using Windows
 98 since it didn't always tell me (at least immediately) I was running
 some buggy code (illegal memory pointers). Linux does a lot better job
 in memory handling.

The problem with Win9x isn't the seg fault detection. The problem is that Win9x doesn't reclaim resources that were being used by a program that exited via a seg fault, so Win9x often became unstable or wedged after a seg fault. It needed to be rebooted upon a seg fault. This misfeature made Win9x unsuitable for development. At the time, I used WinNT for development which didn't have that problem, and ported to Win9x only after it was completely debugged on NT.
Oct 28 2005
prev sibling parent BCS <BCS_member pathlink.com> writes:
In article <djlu53$agr$6 digitaldaemon.com>, Walter Bright says...
I agree with you that your proposal would be very useful for a real mode
operating system like DOS where there are no hardware seg faults or OS
support for them, but DOS is dead and 16 bit systems are not supported by D.


If you're running a 32 bit app under Win9x, you *will* get seg faults if you
dereference NULL, 100% of the time.

I think the point isn't to detect segfalts but to eliminate the need to use a debugger to find the code that generated them. Alternately the program could catch segfalts with it's own interrupt handler and print out a line number or such.
Oct 25 2005
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:dj966n$9km$1 digitaldaemon.com...
 Array bounds errors are not caught by the OS. Code silently continues when 
 you index one past an array but trying to access null generates an 
 immediate segv. So adding code to check for array bounds errors is needed 
 because there is no OS support for it.

Depends on how much / where the memory is allocated. If it happens to be on a page boundary, it might cause a segfault. But this isn't really a counterargument for adding the feature I proposed.
Oct 20 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:dj95ji$964$1 digitaldaemon.com...
 That, and we've already done away with the need to use the debugger to

 segfaults caused by invalid array indices; why not take it the rest of the
 way?

The debugger normally will not find array overruns, because they normally won't cause a seg fault. They'll just cause data corruption, which may or may not eventually result in erratic behavior.
Oct 25 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Jarrett Billingsley wrote:
 We already have array bounds checking in the debug build, accomplished 
 through a sort of implicit assert, such that
 
 int x = array[index];
 
 Becomes
 
 assert(index >= 0 && index < array.length); int x = array[index];
 
 This is to prevent (mostly) the irritating off-by-one errors so common in 
 array handling but which cause a vague memory access violation in 
 nonprotected languages such as C++.  This is a very helpful debugging 
 feature.
 
 I think that a logical extension of this would be to check for null 
 references in debug builds as well.  How many times has trying to call a 
 method of a null reference bitten you?  I propose that this:
 
 obj.doSomething();
 
 Would be implicitly compiled as
 
 assert(obj !is null); obj.doSomething();
 
 This would severly cut down on the amount of "find the segfault" scavenger 
 hunts that are the bane of any programmer's existence.
 
 Since this might severely impact performance, it might even be implemented 
 as a separate compiler switch which could only be used in conjunction with 
 the -debug switch.  Then you could turn it on if you get a segfault and see 
 if it's a null reference that's causing it.
 
 I'm really tired of stepping through code to find segfaults, and I think 
 this would almost entirely eliminate segfaults in D except when dealing with 
 pointers. 
 
 

This would definitely be useful. I've noticed that ~70% of my programming errors are weird segfaults caused by a few nulls in a wrong place. It shouldn't cause too much trouble to include this functionality under the -debug flag. The only downside would be slightly decreased performance. I don't care - why should we care about the speed of debug-mode code in the first place? IMHO only asymptotic time complexity matters. BTW. Has Walter any plans to finally implement the compile-time unit tests?
Oct 20 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I think making it under -debug, which is only for debug {} sections, 
would be a mistake.

-[Unknown]


 Jarrett Billingsley wrote:
 
 We already have array bounds checking in the debug build, accomplished 
 through a sort of implicit assert, such that

 int x = array[index];

 Becomes

 assert(index >= 0 && index < array.length); int x = array[index];

 This is to prevent (mostly) the irritating off-by-one errors so common 
 in array handling but which cause a vague memory access violation in 
 nonprotected languages such as C++.  This is a very helpful debugging 
 feature.

 I think that a logical extension of this would be to check for null 
 references in debug builds as well.  How many times has trying to call 
 a method of a null reference bitten you?  I propose that this:

 obj.doSomething();

 Would be implicitly compiled as

 assert(obj !is null); obj.doSomething();

 This would severly cut down on the amount of "find the segfault" 
 scavenger hunts that are the bane of any programmer's existence.

 Since this might severely impact performance, it might even be 
 implemented as a separate compiler switch which could only be used in 
 conjunction with the -debug switch.  Then you could turn it on if you 
 get a segfault and see if it's a null reference that's causing it.

 I'm really tired of stepping through code to find segfaults, and I 
 think this would almost entirely eliminate segfaults in D except when 
 dealing with pointers.

This would definitely be useful. I've noticed that ~70% of my programming errors are weird segfaults caused by a few nulls in a wrong place. It shouldn't cause too much trouble to include this functionality under the -debug flag. The only downside would be slightly decreased performance. I don't care - why should we care about the speed of debug-mode code in the first place? IMHO only asymptotic time complexity matters. BTW. Has Walter any plans to finally implement the compile-time unit tests?

Oct 22 2005
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Unknown W. Brackets wrote:
 I think making it under -debug, which is only for debug {} sections, 
 would be a mistake.

Probably yes. IMO it should be turned on by default. Only -release and optimized versions should turn it off.
Oct 23 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Jarrett Billingsley wrote:
 We already have array bounds checking in the debug build, accomplished 
 through a sort of implicit assert, such that
 
 int x = array[index];
 
 Becomes
 
 assert(index >= 0 && index < array.length); int x = array[index];
 
 This is to prevent (mostly) the irritating off-by-one errors so common in 
 array handling but which cause a vague memory access violation in 
 nonprotected languages such as C++.  This is a very helpful debugging 
 feature.
 
 I think that a logical extension of this would be to check for null 
 references in debug builds as well.  How many times has trying to call a 
 method of a null reference bitten you?  I propose that this:
 
 obj.doSomething();
 
 Would be implicitly compiled as
 
 assert(obj !is null); obj.doSomething();
 
 This would severly cut down on the amount of "find the segfault" scavenger 
 hunts that are the bane of any programmer's existence.
 
 Since this might severely impact performance, it might even be implemented 
 as a separate compiler switch which could only be used in conjunction with 
 the -debug switch.  Then you could turn it on if you get a segfault and see 
 if it's a null reference that's causing it.
 
 I'm really tired of stepping through code to find segfaults, and I think 
 this would almost entirely eliminate segfaults in D except when dealing with 
 pointers. 
 
 

I think this is a good idea and should be on by default in debug mode, having a flag or something to turn it off if desired. This will save time fiddling with gdb and will give newb's a better impression of the language in general. 'seg fault' with no line number doesn't give a nice impression, and if it can be avoided, then I say do it.
Oct 20 2005
prev sibling next sibling parent llothar <llothar_member pathlink.com> writes:
In article <dj8r60$30s1$1 digitaldaemon.com>, Jarrett Billingsley says...

Since this might severely impact performance, it might even be implemented 
as a separate compiler switch which could only be used in conjunction with 
the -debug switch.  Then you could turn it on if you get a segfault and see 
if it's a null reference that's causing it.

Yes would be nice if we a switch. But with todays superpipelined CPU's it's amazing too see that the condition is almost completely eliminated, means there is no (or maybe a simple one/two clock cycle) additional overhead. I'm still using SmallEiffel and there this technique is the default. I even deliever my final exe's with this options and some more buildin. And don't have any speed problems, even when some parts are heavy CPU intensive
I'm really tired of stepping through code to find segfaults, and I think 
this would almost entirely eliminate segfaults in D except when dealing with 
pointers. 

Yes, D is so bad in offering even simple debugging hints that i find it still not worth using now, and surely wouldn't recommend it for serious developing. Instead adding one feature after the other Walter should focus on development support, not language features at the moment. By the way, when do we get complete tracebacks of the stack after a pre/postcondition is violated, together with writing this to a file (and send back to the developer) so we can get the information even if it is executed on a customers computer ?
Oct 22 2005
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:dj8r60$30s1$1 digitaldaemon.com...
 I think that a logical extension of this would be to check for null
 references in debug builds as well.  How many times has trying to call a
 method of a null reference bitten you?  I propose that this:

 obj.doSomething();

 Would be implicitly compiled as

 assert(obj !is null); obj.doSomething();

But the hardware already does this for you.
 This would severly cut down on the amount of "find the segfault" scavenger
 hunts that are the bane of any programmer's existence.

 Since this might severely impact performance, it might even be implemented
 as a separate compiler switch which could only be used in conjunction with
 the -debug switch.  Then you could turn it on if you get a segfault and

 if it's a null reference that's causing it.

 I'm really tired of stepping through code to find segfaults, and I think
 this would almost entirely eliminate segfaults in D except when dealing

 pointers.

All you need to do is compile with debug on (-g) and run the program under the debugger. When the segfault happens, the debugger will put you right on the line that failed.
Oct 25 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djlu52$agr$4 digitaldaemon.com...
 But the hardware already does this for you.

...
 All you need to do is compile with debug on (-g) and run the program under
 the debugger. When the segfault happens, the debugger will put you right 
 on
 the line that failed.

Which could be entirely bypassed if this check were performed automatically by the program. That, and until there is some kind of integrated dev env for D, using a debugger will always be a chore. That is, unless you really like starting up a separate program, set up the debugger in that so it breaks on acccess violations, running your program through that, and hoping the line mappings are correct and that the debugger can find the source files without being told. I would not imagine that this would be a very difficult feature to implement, and as far as I can tell, there is no good reason not to. D's philosophy is to make things easier, is it not? That, and wouldn't this feature be a pretty nice selling point? "No more vague memory access violations"? I just can't believe that you don't hate segfaults with a passion.
Oct 25 2005
next sibling parent reply "Kris" <fu bar.com> writes:
Jarrett,

Suppose the OS could catch the segfault, fire up a 'dev environment' for 
you, and identify the offending line of code ~ would that suffice?

- Kris


"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:djmq25$26mu$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:djlu52$agr$4 digitaldaemon.com...
 But the hardware already does this for you.

...
 All you need to do is compile with debug on (-g) and run the program 
 under
 the debugger. When the segfault happens, the debugger will put you right 
 on
 the line that failed.

Which could be entirely bypassed if this check were performed automatically by the program. That, and until there is some kind of integrated dev env for D, using a debugger will always be a chore. That is, unless you really like starting up a separate program, set up the debugger in that so it breaks on acccess violations, running your program through that, and hoping the line mappings are correct and that the debugger can find the source files without being told. I would not imagine that this would be a very difficult feature to implement, and as far as I can tell, there is no good reason not to. D's philosophy is to make things easier, is it not? That, and wouldn't this feature be a pretty nice selling point? "No more vague memory access violations"? I just can't believe that you don't hate segfaults with a passion.

Oct 25 2005
parent reply Dan <Dan_member pathlink.com> writes:
Jarret, I would love to see that.
Oct 25 2005
parent xs0 <xs0 xs0.com> writes:
Dan wrote:
 Jarret, I would love to see that.
 
 

Dan, if you don't mind - please quote what you're replying to.. Many people don't read news in a threaded view (me included, obviously), so if you just do it like above, we have no idea what you're talking about ;) xs0
Oct 26 2005
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message
news:djmq25$26mu$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message
 news:djlu52$agr$4 digitaldaemon.com...
 But the hardware already does this for you.
 All you need to do is compile with debug on (-g) and run the program


 the debugger. When the segfault happens, the debugger will put you right
 on
 the line that failed.

Which could be entirely bypassed if this check were performed

 by the program.  That, and until there is some kind of integrated dev env
 for D, using a debugger will always be a chore.  That is, unless you

 like starting up a separate program, set up the debugger in that so it
 breaks on acccess violations, running your program through that, and

 the line mappings are correct and that the debugger can find the source
 files without being told.

I do it all the time, it isn't a chore. Instead of: C> foo args... I type in: C> windbg foo.exe args... and click on run in the debugger. When it segfaults, I get a nice call stack, with source or asm display for each entry in the call stack. The debugger doesn't need to be set up for breaking on access violations, it can't *not* do it. Unless you've moved the source files or the executable, it finds them.
 I would not imagine that this would be a very difficult feature to
 implement, and as far as I can tell, there is no good reason not to.  D's
 philosophy is to make things easier, is it not?  That, and wouldn't this
 feature be a pretty nice selling point?  "No more vague memory access
 violations"?  I just can't believe that you don't hate segfaults with a
 passion.

My views on seg faults were shaped from the bad old DOS days when you didn't get seg faults, you discovered something was wrong with your program when your hard disk was scrambled and you had to restore your entire hard disk. I *love* seg faults because it pinpoints a bug in your program usually very close to where it actually is. I don't have to reboot anymore or constantly be restoring my hard disk. Seg faults are the biggest advance in programmer productivity since compilers.
Oct 28 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
if it's a null reference that's causing it.

I'm really tired of stepping through code to find segfaults, and I think
this would almost entirely eliminate segfaults in D except when dealing

with
pointers.

All you need to do is compile with debug on (-g) and run the program under the debugger. When the segfault happens, the debugger will put you right on the line that failed.

(or AccessViolation), and then dump a stack trace (à la Java) would be nice, altough not prioritary I guess. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 26 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message
news:djnh7c$16h2$1 digitaldaemon.com...
 Still, having the compiler throw a NullPointerException on a segfault
 (or AccessViolation), and then dump a stack trace (à la Java) would be
 nice, altough not prioritary I guess.

I agree, it would be nice. But it isn't trivial to implement, the capability is already available via the debugger, and other missing things have much higher priority (like shared library support, better symbolic debug info, etc.).
Oct 28 2005
prev sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Thu, 20 Oct 2005 15:29:05 -0400, Jarrett Billingsley wrote:

 We already have array bounds checking in the debug build, accomplished 
 through a sort of implicit assert, such that
 
 int x = array[index];
 
 Becomes
 
 assert(index >= 0 && index < array.length); int x = array[index];
 

I like your idea why don't you add it to the unofficial wish list ? http://all-technology.com/eigenpolls/dwishlist/
Oct 27 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Knud Sørensen" <12tkvvb02 sneakemail.com> wrote in message 
news:pan.2005.10.27.11.56.43.124177 sneakemail.com...
 I like your idea why don't you add it to the unofficial wish list ?

Done. Though who knows if it'll make much of a difference..
Oct 27 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Knud Sørensen wrote:
 I like your idea why don't you add it to the unofficial wish list ?
 
 http://all-technology.com/eigenpolls/dwishlist/

Return-type overloading as the number one feature?? That is just plain nuts! -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 27 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:

 Knud Sørensen wrote:
 I like your idea why don't you add it to the unofficial wish list ?
 
 http://all-technology.com/eigenpolls/dwishlist/

Return-type overloading as the number one feature?? That is just plain nuts!

Yes, I often thought that the scoring algorithm for this poll is wrong. It seems to only take into consideration the relative ranking of each item within each submitter's list, but it should also consider the number of submitters for each item as a factor. Currently, if one person puts a new item as their #1 priority, that items shots to the top of the list. Conversely, if you wish to reduce the ranking of an item it is better to include it in your personal list at the bottom than to not vote for it at all. -- Derek (skype: derek.j.parnell) Melbourne, Australia 28/10/2005 6:41:43 PM
Oct 28 2005
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Derek Parnell wrote:
 On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:
 
 
Knud Sørensen wrote:

I like your idea why don't you add it to the unofficial wish list ?

http://all-technology.com/eigenpolls/dwishlist/

Return-type overloading as the number one feature?? That is just plain nuts!

Yes, I often thought that the scoring algorithm for this poll is wrong. It seems to only take into consideration the relative ranking of each item within each submitter's list, but it should also consider the number of submitters for each item as a factor. Currently, if one person puts a new item as their #1 priority, that items shots to the top of the list. Conversely, if you wish to reduce the ranking of an item it is better to include it in your personal list at the bottom than to not vote for it at all.

It's a ridiculous algorithm. At least you'd get relatively sensible results if you ordered by number of votes.
Oct 28 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:
 Derek Parnell wrote:
 
 On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:


 Knud Sørensen wrote:

 I like your idea why don't you add it to the unofficial wish list ?

 http://all-technology.com/eigenpolls/dwishlist/

Return-type overloading as the number one feature?? That is just plain nuts!

Yes, I often thought that the scoring algorithm for this poll is wrong. It seems to only take into consideration the relative ranking of each item within each submitter's list, but it should also consider the number of submitters for each item as a factor. Currently, if one person puts a new item as their #1 priority, that items shots to the top of the list. Conversely, if you wish to reduce the ranking of an item it is better to include it in your personal list at the bottom than to not vote for it at all.

It's a ridiculous algorithm. At least you'd get relatively sensible results if you ordered by number of votes.

Right. And if one wants to give much priority to his pets, then include every other suggestion too, below the pet. So, everybody ends up having all entries in their list, which only results in most other than the top/bottom few being in more or less an arbitrary order. Which of course invalidates the entire purpose of the algorithm. Not to mention, such lists tend to become lists of nice features, with no regard to the relative effort or priority of each. A nice sounding cool feature gets higher than an essential feature that is not possible to explain to newbies or passers-by with only a half sentence.
Oct 29 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:
 On Thu, 27 Oct 2005 21:50:46 +0100, Bruno Medeiros wrote:
 
 
Knud Sørensen wrote:

I like your idea why don't you add it to the unofficial wish list ?

http://all-technology.com/eigenpolls/dwishlist/

Return-type overloading as the number one feature?? That is just plain nuts!

Yes, I often thought that the scoring algorithm for this poll is wrong.

a simple one), but I don't think a poll system works at all for that purpose. One should have a voting/ranking for each individual feature/change, not a ranking amongst them. And it would also need the following: * User Autentication (to avoid duplicate votes) * Allow negative voting. (i.e. deslike) -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Oct 29 2005