www.digitalmars.com         C & C++   DMDScript  

c++ - DebugBreak()

reply dan <dan_member pathlink.com> writes:
I'm using windows.h 's DebugBreak() and it invariably takes me to a disassembly
window. Also the IDE is acting up on me today, won't open files on me either
from the menu File->Open or from double-clicking on the error line in the output
window;  and I see files in the Window menu that I closed earlier, but it seems
to think they are still open... Tried closing and restarting the IDE, tried
rebooting the machine twice. Something must have got corrupted with the project
file, I suppose...?

dan
Jan 03 2004
next sibling parent "Walter" <walter digitalmars.com> writes:
"dan" <dan_member pathlink.com> wrote in message
news:bt7g7i$1q5a$1 digitaldaemon.com...
 I'm using windows.h 's DebugBreak() and it invariably takes me to a

 window. Also the IDE is acting up on me today, won't open files on me

 from the menu File->Open or from double-clicking on the error line in the

 window;  and I see files in the Window menu that I closed earlier, but it

 to think they are still open... Tried closing and restarting the IDE,

 rebooting the machine twice. Something must have got corrupted with the

 file, I suppose...?

Try deleting and rebuilding the project file.
Jan 03 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Uses inline and do an int 3 if you want it to stop in your code, rather than
within the implementation of DebugBreak (which does an int 3)

"dan" <dan_member pathlink.com> wrote in message
news:bt7g7i$1q5a$1 digitaldaemon.com...
 I'm using windows.h 's DebugBreak() and it invariably takes me to a

 window. Also the IDE is acting up on me today, won't open files on me

 from the menu File->Open or from double-clicking on the error line in the

 window;  and I see files in the Window menu that I closed earlier, but it

 to think they are still open... Tried closing and restarting the IDE,

 rebooting the machine twice. Something must have got corrupted with the

 file, I suppose...?

 dan

Jan 03 2004
parent reply dan <dan_member pathlink.com> writes:
In article <bt8e9c$42q$2 digitaldaemon.com>, Matthew says...
Uses inline and do an int 3 if you want it to stop in your code, rather than
within the implementation of DebugBreak (which does an int 3)

Works like a charm, thx!
Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 In article <bt8e9c$42q$2 digitaldaemon.com>, Matthew says...
Uses inline and do an int 3 if you want it to stop in your code, rather


within the implementation of DebugBreak (which does an int 3)

Works like a charm, thx!

Pleasure. :)
Jan 04 2004
parent reply dan <dan_member pathlink.com> writes:
//file: verify.hpp
#ifndef VERIFY_HPP
#define VERIFY_HPP

#ifdef _DEBUG
# define verify(x) do{ if( !((x)) ) asm int 3; }while(0)
#else
# define verify(x) (void)(0)
#endif

/*
// Usage example:
#include "verify.hpp"
#include <stdio.h>
char first_char( char const * s )
{
verify( s && ::strlen(s) );
return s[0];
}
// Cheers!
// dan
*/

#endif
Jan 05 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
No! verify() has a well established semantic to be === to assert in debug
mode, but to not elide the expression in release mode. In other words, the
side effects of the expression are always present in the executable.

Frankly, I hate those semantics, as it's constantly misused and mistaken for
assert, and vice versa, but creating your own verify() that is === assert()
will only add to the confusion. Make it my_assert() or something.

"dan" <dan_member pathlink.com> wrote in message
news:btb8jc$1koi$1 digitaldaemon.com...
 //file: verify.hpp
 #ifndef VERIFY_HPP
 #define VERIFY_HPP

 #ifdef _DEBUG
 # define verify(x) do{ if( !((x)) ) asm int 3; }while(0)
 #else
 # define verify(x) (void)(0)
 #endif

 /*
 // Usage example:
 #include "verify.hpp"
 #include <stdio.h>
 char first_char( char const * s )
 {
 verify( s && ::strlen(s) );
 return s[0];
 }
 // Cheers!
 // dan
 */

 #endif

Jan 05 2004
parent reply dan <dan_member pathlink.com> writes:
No! verify() has a well established semantic to be === to assert in debug
mode, but to not elide the expression in release mode. In other words, the
side effects of the expression are always present in the executable.

Frankly, I hate those semantics, as it's constantly misused and mistaken for
assert, and vice versa, but creating your own verify() that is === assert()
will only add to the confusion. Make it my_assert() or something.

You're right on all counts. I just learned of the evil existence of verify() at the boost forum. And I hate that too: In my coding I religiously respect command <-> query separation: Either a function returns a value but has no side-effects; or it has effects but returns void. To think that a variant on assert would be designed to support such bad coding makes my blood boil. How about, //file: ensure.hpp #ifndef ENSURE_HPP #define ENSURE_HPP #ifdef _DEBUG # define ENSURE(x) do{ if( !((x)) ) asm int 3; }while(0) #else # define ENSURE(x) (void)(0) #endif /* // Usage example: #include "ensure.hpp" #include <stdio.h> char first_char( char const * s ) { ENSURE( s && ::strlen(s) ); return s[0]; } // Cheers! // dan */ ?
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
No! verify() has a well established semantic to be === to assert in debug
mode, but to not elide the expression in release mode. In other words,


side effects of the expression are always present in the executable.

Frankly, I hate those semantics, as it's constantly misused and mistaken


assert, and vice versa, but creating your own verify() that is ===


will only add to the confusion. Make it my_assert() or something.

You're right on all counts. I just learned of the evil existence of

 the boost forum.  And I hate that too:  In my coding I religiously respect
 command <-> query separation:  Either a function returns a value but has

 side-effects;  or it has effects but returns void.  To think that a

 assert would be designed to support such bad coding makes my blood boil.
 How about,

Cool. After pressing send I worried that I'd come on a bit strong. (It's nearly midnight here)
 //file: ensure.hpp
 #ifndef ENSURE_HPP
 #define ENSURE_HPP

 #ifdef _DEBUG
 # define ENSURE(x) do{ if( !((x)) ) asm int 3; }while(0)
 #else
 # define ENSURE(x) (void)(0)
 #endif

 /*
 // Usage example:
 #include "ensure.hpp"
 #include <stdio.h>
 char first_char( char const * s )
 {
 ENSURE( s && ::strlen(s) );
 return s[0];
 }
 // Cheers!
 // dan
 */

Sure. ENSURE is as good as anything else. :)
Jan 05 2004
parent reply dan <dan_member pathlink.com> writes:
Sure. ENSURE is as good as anything else. :)

Better than "assert", which, in English, means to "proclaim" or "emphatically say"; NOT to "verify" or "ensure" or "test" as it does. ;-) By the way, if you haven't gone to sleep yet, is there a way I can continue debugging after an int 3? I want to be able to single step or continue running after an ENSURE clause fails, if I want to. Right now the debugger stops, and all I can do is re-start execution... dan
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
int 3 gives a continuable exception, so if your debugger is up to it (as I
would expect it would) then continuing should be a no-brainer. If it's not,
though, I'm not much of an expert any deeper than what we've touched on, so
you'll be on your own. ;/

"dan" <dan_member pathlink.com> wrote in message
news:btbn6d$2bll$1 digitaldaemon.com...
Sure. ENSURE is as good as anything else. :)

Better than "assert", which, in English, means to "proclaim" or

 say";  NOT to "verify" or "ensure" or "test" as it does.  ;-)

 By the way, if you haven't gone to sleep yet, is there a way I can

 debugging after an int 3?  I want to be able to single step or continue

 after an ENSURE clause fails, if I want to.  Right now the debugger stops,

 all I can do is re-start execution...

 dan

Jan 05 2004
parent dan <dan_member pathlink.com> writes:
int 3 gives a continuable exception, so if your debugger is up to it (as I
would expect it would) then continuing should be a no-brainer. If it's not,
though, I'm not much of an expert any deeper than what we've touched on, so
you'll be on your own. ;/

You've been IMMENSLY helpful. My previous implementation of ENSURE() had a class with a static function that had to be in a CPP file, plus a fancy macro, and an overloaded global comma operator. Your int 3 tip got all that down to 5 lines, for me. As for continuing, maybe Walter knows what's going on. But for now I can use this as it is, I don't mind re-starting the debugging session, for now. And, by the way, thanks Walter; deleting the prj file worked. (Actually, I deleted all the files there.) Now I back them up twice a day.
Jan 05 2004
prev sibling parent reply "Sean" <seanchen telus.net> writes:
Forgive my ignorance but why the do and while? What's wrong if just
 # define verify(x) if( !((x)) ) asm int 3;
or
 # define verify(x) { if( !((x)) ) asm int 3; }



 //file: verify.hpp
 #ifndef VERIFY_HPP
 #define VERIFY_HPP

 #ifdef _DEBUG
 # define verify(x) do{ if( !((x)) ) asm int 3; }while(0)
 #else
 # define verify(x) (void)(0)
 #endif

 /*
 // Usage example:
 #include "verify.hpp"
 #include <stdio.h>
 char first_char( char const * s )
 {
 verify( s && ::strlen(s) );
 return s[0];
 }
 // Cheers!
 // dan
 */

 #endif

Jan 05 2004
parent reply "Gisle Vanem" <giva users.sourceforge.net> writes:
"Sean" <seanchen telus.net> wrote:

 Forgive my ignorance but why the do and while? What's wrong if just
  # define verify(x) if( !((x)) ) asm int 3;
 or
  # define verify(x) { if( !((x)) ) asm int 3; }

I'll ignore "your ignorance" :) What would the compiler say about: if (foo) verify (x); else verify (y); The ';' would cause a parse error in both cases. And in the 1st case, the 'else' wouldn't be for the outer 'if', but the one in the macro. --gv
Jan 05 2004
parent reply "Sean" <seanchen telus.net> writes:
I see, thanks.

"Gisle Vanem" <giva users.sourceforge.net> ????
news:btdi7k$2759$1 digitaldaemon.com...
 "Sean" <seanchen telus.net> wrote:

 Forgive my ignorance but why the do and while? What's wrong if just
  # define verify(x) if( !((x)) ) asm int 3;
 or
  # define verify(x) { if( !((x)) ) asm int 3; }

I'll ignore "your ignorance" :) What would the compiler say about: if (foo) verify (x); else verify (y); The ';' would cause a parse error in both cases. And in the 1st case, the 'else' wouldn't be for the outer 'if', but the one in the macro. --gv

Jan 05 2004
parent "Nic Tiger" <tiger7 progtech.ru> writes:
For if cases I usually use following form:
    #define check(x) if (x) do_something; else
Than you are forced to write ; after check, i.e.    check(a>b);
But you have no problems with else and other stuff.

Nic Tiger.

"Sean" <seanchen telus.net> wrote in message
news:btdp5g$2h08$1 digitaldaemon.com...
 I see, thanks.

 "Gisle Vanem" <giva users.sourceforge.net> ????
 news:btdi7k$2759$1 digitaldaemon.com...
 "Sean" <seanchen telus.net> wrote:

 Forgive my ignorance but why the do and while? What's wrong if just
  # define verify(x) if( !((x)) ) asm int 3;
 or
  # define verify(x) { if( !((x)) ) asm int 3; }

I'll ignore "your ignorance" :) What would the compiler say about: if (foo) verify (x); else verify (y); The ';' would cause a parse error in both cases. And in the 1st case,


 'else' wouldn't be for the outer 'if', but the one in the macro.

 --gv


Jan 06 2004