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


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


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


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




than

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

#else

#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

 #else

 #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

#else

#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,




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,


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

 #else

 #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


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

or





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

 #ifdef _DEBUG

 #else

 #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

 or



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

 or



 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

 or



 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 06 2004