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

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

Jarret, I would love to see that.

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


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

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

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/

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

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

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

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.