release build assertions/verifications

[Angel Tsankov]

I need to make verifications in release builds. If a verification
fails, an error message should be displayed and the program should be
aborted. I need this solution to be portable. Then I thought of the
assert macro - it provides the desired functionality but only if
NDEBUG is not defined. So, I could write smth like this:

#if defined NDEBUG
#undef NDEBUG
#include <cassert>
#define NDEBUG
#else
#include <cassert>
#endif

Unfortunately, NDEBUG could be defined to something meaningful, in
which case it's value would be lost.

Can anyone think of some other way to use the assert macro for
verification?
What about any other options?

Regards,
Angel Tsankov

[mlimber]

Angel Tsankov wrote:

I need to make verifications in release builds. If a verification
fails, an error message should be displayed and the program should be
aborted. I need this solution to be portable. Then I thought of the
assert macro - it provides the desired functionality but only if
NDEBUG is not defined. So, I could write smth like this:

#if defined NDEBUG
#undef NDEBUG
#include <cassert>
#define NDEBUG
#else
#include <cassert>
#endif

Unfortunately, NDEBUG could be defined to something meaningful, in
which case it's value would be lost.

Can anyone think of some other way to use the assert macro for
verification?
What about any other options?

Regards,
Angel Tsankov

I have implemented my own macros, which are similar to Microsoft's.
Something like:

class MyException
{
MyException( const char* msg );
const char* what() const;
};

#define VERIFY(cond) if(cond); else throw MyException( #cond )
#if defined( NDEBUG )
# define ASSERT(cond) VERIFY(cond)
#else
# define ASSERT(cond)
#endif

Of course, you can make your VERIFY do something other than throw an
exception. Remember to use compile-time assertions wherever possible
instead of run-time assertions.

Cheers! --M

[Angel Tsankov]

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

Angel Tsankov wrote:

I need to make verifications in release builds. If a verification
fails, an error message should be displayed and the program should
be
aborted. I need this solution to be portable. Then I thought of the
assert macro - it provides the desired functionality but only if
NDEBUG is not defined. So, I could write smth like this:

#if defined NDEBUG
#undef NDEBUG
#include <cassert>
#define NDEBUG
#else
#include <cassert>
#endif

Unfortunately, NDEBUG could be defined to something meaningful, in
which case it's value would be lost.

Can anyone think of some other way to use the assert macro for
verification?
What about any other options?

Regards,
Angel Tsankov

I have implemented my own macros, which are similar to Microsoft's.
Something like:

class MyException
{
MyException( const char* msg );
const char* what() const;
};

#define VERIFY(cond) if(cond); else throw MyException( #cond )
#if defined( NDEBUG )
# define ASSERT(cond) VERIFY(cond)
#else
# define ASSERT(cond)
#endif

Of course, you can make your VERIFY do something other than throw an
exception.

I want my VERIFY to display a message and abort the program. The
problem is where to display the message - send it to std::cerr, use a
message box, file or what? It would also be nice if the solution is
portable. The assert macro takes care of where to output the message
and is portable. That's why I'm considering it. However, as I
mentiond, there is a slight problem with it - its value can get lost
when I #undef it. So, I'm asking for ideas how to cope with this
problem. I'd also appreciate any other relevant ideas.

[mlimber]

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

Angel Tsankov wrote:

I need to make verifications in release builds. If a verification
fails, an error message should be displayed and the program should
be
aborted. I need this solution to be portable. Then I thought of the
assert macro - it provides the desired functionality but only if
NDEBUG is not defined. So, I could write smth like this:

#if defined NDEBUG
#undef NDEBUG
#include <cassert>
#define NDEBUG
#else
#include <cassert>
#endif

Unfortunately, NDEBUG could be defined to something meaningful, in
which case it's value would be lost.

Can anyone think of some other way to use the assert macro for
verification?
What about any other options?

Regards,
Angel Tsankov

I have implemented my own macros, which are similar to Microsoft's.
Something like:

class MyException
{
MyException( const char* msg );
const char* what() const;
};

#define VERIFY(cond) if(cond); else throw MyException( #cond )
#if defined( NDEBUG )
# define ASSERT(cond) VERIFY(cond)
#else
# define ASSERT(cond)
#endif

Of course, you can make your VERIFY do something other than throw an
exception.

I want my VERIFY to display a message and abort the program. The
problem is where to display the message - send it to std::cerr, use a
message box, file or what? It would also be nice if the solution is
portable. The assert macro takes care of where to output the message
and is portable. That's why I'm considering it. However, as I
mentiond, there is a slight problem with it - its value can get lost
when I #undef it. So, I'm asking for ideas how to cope with this
problem. I'd also appreciate any other relevant ideas.

My relevant idea was given in the previous post. Just substitute your
desired behavior for the throwing of the exception. You could output to
std::cerr and call std::exit, for instance.

Cheers! --M

[Angel Tsankov]

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

> Angel Tsankov wrote:
>> I need to make verifications in release builds. If a
>> verification
>> fails, an error message should be displayed and the program
>> should
>> be
>> aborted. I need this solution to be portable. Then I thought of
>> the
>> assert macro - it provides the desired functionality but only if
>> NDEBUG is not defined. So, I could write smth like this:
>>
>> #if defined NDEBUG
>> #undef NDEBUG
>> #include <cassert>
>> #define NDEBUG
>> #else
>> #include <cassert>
>> #endif
>>
>> Unfortunately, NDEBUG could be defined to something meaningful,
>> in
>> which case it's value would be lost.
>>
>> Can anyone think of some other way to use the assert macro for
>> verification?
>> What about any other options?
>>
>> Regards,
>> Angel Tsankov
>
> I have implemented my own macros, which are similar to
> Microsoft's.
> Something like:
>
> class MyException
> {
> MyException( const char* msg );
> const char* what() const;
> };
>
> #define VERIFY(cond) if(cond); else throw MyException( #cond )
> #if defined( NDEBUG )
> # define ASSERT(cond) VERIFY(cond)
> #else
> # define ASSERT(cond)
> #endif
>
> Of course, you can make your VERIFY do something other than throw
> an
> exception.

I want my VERIFY to display a message and abort the program. The
problem is where to display the message - send it to std::cerr, use
a
message box, file or what? It would also be nice if the solution is
portable. The assert macro takes care of where to output the
message
and is portable. That's why I'm considering it. However, as I
mentiond, there is a slight problem with it - its value can get
lost
when I #undef it. So, I'm asking for ideas how to cope with this
problem. I'd also appreciate any other relevant ideas.

My relevant idea was given in the previous post. Just substitute
your
desired behavior for the throwing of the exception. You could output
to
std::cerr and call std::exit, for instance.

Output to std:cerr gets "lost" in GUI-based applications.

[mlimber]

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message

My relevant idea was given in the previous post. Just substitute
your
desired behavior for the throwing of the exception. You could output
to
std::cerr and call std::exit, for instance.

Output to std:cerr gets "lost" in GUI-based applications.

The problem is not that cerr is not portable but that GUIs aren't.
Another portable alternative is writing to a log file, but personally,
I think throwing an exception that contains the error message (see my
first post) is the cleanest option. In such a case, you use the same
error reporting tool in the code, but supply an appropriate handler for
each platform, e.g.:

// For some GUI API
try
{
DoSomething();
}
catch( const MyException& e )
{
DialogBox( string("Error: ") + e.what() + " Terminating." );
exit( -1 );
}

// For some console application
try
{
DoSomething();
}
catch( const MyException& e )
{
cerr << ""Error: " << e.what() << " Terminating" << endl;
exit( -1 );
}

// For some program with no console attached
try
{
DoSomething();
}
catch( const MyException& e )
{
ofstream log( "log.txt", ios::app );
log << ""Error: " << e.what() << " Terminating" << endl;
exit( -1 );
}

Cheers! --M

[Angel Tsankov]

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message

> My relevant idea was given in the previous post. Just substitute
> your
> desired behavior for the throwing of the exception. You could
> output
> to
> std::cerr and call std::exit, for instance.
>

Output to std:cerr gets "lost" in GUI-based applications.

The problem is not that cerr is not portable but that GUIs aren't.
Another portable alternative is writing to a log file, but
personally,
I think throwing an exception that contains the error message (see
my
first post) is the cleanest option.

The reason why I'd rather avoid this approach is that I am concerned
about using it in dtors.

[mlimber]

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message

The problem is not that cerr is not portable but that GUIs aren't.
Another portable alternative is writing to a log file, but
personally,
I think throwing an exception that contains the error message (see
my
first post) is the cleanest option.

The reason why I'd rather avoid this approach is that I am concerned
about using it in dtors.

Then, perhaps the best solution is an ostream-based log. You could
accept an ostream reference or (smart) pointer in your classes'
constructors, and they could use it to write their messages. Then on
different platforms, you could pass the ostream-type object (e.g.,
std::cerr, a std::ofstream for a log file, a std::stringstre am) that
best suits that platform.

Cheers! --M

[Angel Tsankov]

"mlimber" <ml*****@gmail. com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message

> The problem is not that cerr is not portable but that GUIs
> aren't.
> Another portable alternative is writing to a log file, but
> personally,
> I think throwing an exception that contains the error message
> (see
> my
> first post) is the cleanest option.

The reason why I'd rather avoid this approach is that I am
concerned
about using it in dtors.

Then, perhaps the best solution is an ostream-based log. You could
accept an ostream reference or (smart) pointer in your classes'
constructors, and they could use it to write their messages.

Well, I'm sorry to tell you but I can see another flaw with your
suggestion - my class cannot have a default ctor.

[mlimber]

Angel Tsankov wrote:

"mlimber" <ml*****@gmail. com> wrote in message

Then, perhaps the best solution is an ostream-based log. You could
accept an ostream reference or (smart) pointer in your classes'
constructors, and they could use it to write their messages.

Well, I'm sorry to tell you but I can see another flaw with your
suggestion - my class cannot have a default ctor.

So what's the problem? If you followed the plan mentioned above, there
would be no default constructor.

Cheers! --M