"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.

"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 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.

"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.).

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.

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.
Indeed. I think a feature/change feedback system would be nice (even if 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."