"Derek Parnell" <derek@psych.ward> wrote in message news:ce7ijg$30vm$1@digitaldaemon.com...
> >> Because assert() gives us filename and line number, but "Access
Violation"
> >> doesn't.
> >
> > Run it under the debugger, and the debugger will open up a window and
put
> > the cursor on it <g>.
>
> Sorry, too glib. Not impressed.
>
> Why bother having assert give this info?

Because debuggers don't work off of asserts.

> And which "the debugger" are you referring to?

Most any debugger will do it. In fact, it's one of the main features of a semi-decent debugger. I can't remember any protected mode debugger that didn't do it. Debuggers will also give a stack trace, which is so useful that sometimes I'll replace the assert with a *(char*)0=0; just to run it under a debugger to get the stack trace.

GPFs have an undeservedly bad rap. There's nothing inherently worse about it than an assert failure. They're really the same thing, and the GPF has the nice feature that you get such checking with 0 extra overhead (unlike asserts). The GPF does in hardware what the assert does in software, that's all.

In article <ce77fg$2sh7$1@digitaldaemon.com>, Walter says...
>
>
>"Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.07.28.03.06.34.780054@yahoo.ca...
>> On Tue, 27 Jul 2004 20:02:06 -0700, Andy Friesen wrote:
>>
>> >
>> > assert(a); is a special case in the language: it is not a boolean not-null test, it runs A's invariant to assert that 'a' is correct.
>>
>> I didn't know that, cheking documentation ... checked, good!
>>
>> >
>> > Still, you would think that an assertion failure would trip, since part of Object.invariant is "assert(this!==null);"
>> >
>>
>> so looks like a bug, smells like a bug, is it a bug?
>
>No. assert(a) doesn't bother checking to see if a is null before calling the invariant, because the hardware will do that for you. Why duplicate what the hardware does?

To give a line number and file name to the poor guy that spends hours looking at his or someone else's code?

Ant

In article <ce7fjr$30a6$1@digitaldaemon.com>, Walter says...
>
>
>Run it under the debugger, and the debugger will open up a window and put the cursor on it <g>.

Is it possible under linux?
(I know I asked this before and nobody answer, I promiss I won't ask again)

Walter sais he uses gdb but I can't convince it to show the D source (no problem with C source).

Ant

Ant wrote:

> In article <ce7fjr$30a6$1@digitaldaemon.com>, Walter says...
>>
>>
>>Run it under the debugger, and the debugger will open up a window and put the cursor on it <g>.
> 
> Is it possible under linux?
> (I know I asked this before and nobody answer, I promiss I won't ask
> again)
> 
> Walter sais he uses gdb but I can't convince it to show the
> D source (no problem with C source).
> 
> Ant

I've been using gdb but I've noticed
1) the source doesn't show up - annoying but not a big deal for me since I
don't have much code
2) sometimes the stack traces printed out by "bt" look pretty messed up even
for simple things
3) I can't look at variables when stopped

In article <ce86dc$7pd$1@digitaldaemon.com>, Ben Hinkle says...
>
>I've been using gdb but I've noticed
>1) the source doesn't show up - annoying but not a big deal for me since I
>don't have much code
>2) sometimes the stack traces printed out by "bt" look pretty messed up even
>for simple things
>3) I can't look at variables when stopped

So, why do you use it? What can you get?
(It's an honest question. not a joke)
What do you get from it?

I've been using it (with DDD front end) to debug the interface with
C (on DUI) but it doesn't help me with D.

Ant

Ant wrote:

> In article <ce86dc$7pd$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>I've been using gdb but I've noticed
>>1) the source doesn't show up - annoying but not a big deal for me since I
>>don't have much code
>>2) sometimes the stack traces printed out by "bt" look pretty messed up
>>even for simple things
>>3) I can't look at variables when stopped
> 
> So, why do you use it? What can you get?
> (It's an honest question. not a joke)
> What do you get from it?

usually the stack trace is correct. that's all I use it for.

> I've been using it (with DDD front end) to debug the interface with
> C (on DUI) but it doesn't help me with D.
> 
> Ant

can't assert print the stack (if you have the frame pointer)?
I mean you just need some logic that does the same thing that the debugger would do...and call that on an assert...
it's useless to have an assert not throw a signal otherwise...usually the assert isn't where the problem is occuring, but n frame(s) above it.


Walter wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message
> news:ce7ijg$30vm$1@digitaldaemon.com...
> 
>>>>Because assert() gives us filename and line number, but "Access
> 
> Violation"
> 
>>>>doesn't.
>>>
>>>Run it under the debugger, and the debugger will open up a window and
> 
> put
> 
>>>the cursor on it <g>.
>>
>>Sorry, too glib. Not impressed.
>>
>>Why bother having assert give this info?
> 
> 
> Because debuggers don't work off of asserts.
> 
> 
>>And which "the debugger" are you referring to?
> 
> 
> Most any debugger will do it. In fact, it's one of the main features of a
> semi-decent debugger. I can't remember any protected mode debugger that
> didn't do it. Debuggers will also give a stack trace, which is so useful
> that sometimes I'll replace the assert with a *(char*)0=0; just to run it
> under a debugger to get the stack trace.
> 
> GPFs have an undeservedly bad rap. There's nothing inherently worse about it
> than an assert failure. They're really the same thing, and the GPF has the
> nice feature that you get such checking with 0 extra overhead (unlike
> asserts). The GPF does in hardware what the assert does in software, that's
> all.
> 
> 

Dixit Derek Parnell says:

>On Tue, 27 Jul 2004 20:41:56 -0700, Walter wrote:
>> 
>> No. assert(a) doesn't bother checking to see if a is null before calling the invariant, because the hardware will do that for you. Why duplicate what the hardware does?
>
>Because assert() gives us filename and line number, but "Access Violation"
>doesn't.

Also, you can try/catch the assert if you're so inclined.

Nick

"Daniel Horn" <hellcatv@hotmail.com> wrote in message news:ce8nrb$es2$2@digitaldaemon.com...
> can't assert print the stack (if you have the frame pointer)?
> I mean you just need some logic that does the same thing that the
> debugger would do...and call that on an assert...
> it's useless to have an assert not throw a signal otherwise...usually
> the assert isn't where the problem is occuring, but n frame(s) above it.

It's not so easy since the debug data needed is sometimes separate. The debugger has the debug data, and so can do a stack trace easilly. That's why I sometimes replace an assert with *(char*)0=0;.

"Ant" <Ant_member@pathlink.com> wrote in message news:ce83ht$6in$1@digitaldaemon.com...
> In article <ce7fjr$30a6$1@digitaldaemon.com>, Walter says...
> >
> >
> >Run it under the debugger, and the debugger will open up a window and put the cursor on it <g>.
>
> Is it possible under linux?
> (I know I asked this before and nobody answer, I promiss I won't ask
again)
>
> Walter sais he uses gdb but I can't convince it to show the
> D source (no problem with C source).

That's because I've been lazy and have not gotten the debug data written out correctly in the elf format. gdb will, however, give the stack trace, and with the 'disassemble' command will show you which instruction failed, which if you turn optimization off is pretty easy to spot which line it is on.