digitalmars.D - Proposal - Check for null reference in debug build
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Oct 20 2005
- "Ameer Armaly" <ameer_armaly hotmail.com> Oct 20 2005
- "Ben Hinkle" <bhinkle mathworks.com> Oct 20 2005
- =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> Oct 20 2005
- Sean Kelly <sean f4.ca> Oct 20 2005
- "Ben Hinkle" <ben.hinkle gmail.com> Oct 20 2005
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Oct 20 2005
- "Ben Hinkle" <ben.hinkle gmail.com> Oct 20 2005
- =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> Oct 20 2005
- "Walter Bright" <newshound digitalmars.com> Oct 25 2005
- =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> Oct 25 2005
- "Walter Bright" <newshound digitalmars.com> Oct 28 2005
- BCS <BCS_member pathlink.com> Oct 25 2005
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Oct 20 2005
- "Walter Bright" <newshound digitalmars.com> Oct 25 2005
- =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> Oct 20 2005
- clayasaurus <clayasaurus gmail.com> Oct 20 2005
- llothar <llothar_member pathlink.com> Oct 22 2005
- "Walter Bright" <newshound digitalmars.com> Oct 25 2005
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Oct 25 2005
- "Kris" <fu bar.com> Oct 25 2005
- Dan <Dan_member pathlink.com> Oct 25 2005
- xs0 <xs0 xs0.com> Oct 26 2005
- "Walter Bright" <newshound digitalmars.com> Oct 28 2005
- Bruno Medeiros <daiphoenixNO SPAMlycos.com> Oct 26 2005
- "Walter Bright" <newshound digitalmars.com> Oct 28 2005
- =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> Oct 27 2005
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Oct 27 2005
- Bruno Medeiros <daiphoenixNO SPAMlycos.com> Oct 27 2005
- Derek Parnell <derek psych.ward> Oct 28 2005
- Don Clugston <dac nospam.com.au> Oct 28 2005
- Georg Wrede <georg.wrede nospam.org> Oct 29 2005
- Bruno Medeiros <daiphoenixNO SPAMlycos.com> Oct 29 2005
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
"Ameer Armaly" <ameer_armaly hotmail.com> 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
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
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
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
"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
"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
"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
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
"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
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
"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
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
"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
"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
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
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
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
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
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 intensiveI'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
"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
"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
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
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
"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
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
withpointers.
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
"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
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
"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
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
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
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
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
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