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

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

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