• dan <dan_member pathlink.com> Jan 03 2004
• "Walter" <walter digitalmars.com> Jan 03 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jan 03 2004
• dan <dan_member pathlink.com> Jan 04 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jan 04 2004
• dan <dan_member pathlink.com> Jan 05 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jan 05 2004
• dan <dan_member pathlink.com> Jan 05 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jan 05 2004
• dan <dan_member pathlink.com> Jan 05 2004
• "Matthew" <matthew.hat stlsoft.dot.org> Jan 05 2004
• dan <dan_member pathlink.com> Jan 05 2004
• "Sean" <seanchen telus.net> Jan 05 2004
• "Gisle Vanem" <giva users.sourceforge.net> Jan 05 2004
• "Sean" <seanchen telus.net> Jan 05 2004
• "Nic Tiger" <tiger7 progtech.ru> Jan 06 2004

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

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

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

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!

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

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

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

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

?

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

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

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

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.

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

"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

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

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