473,325 Members | 2,860 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

release build assertions/verifications

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

Jan 24 '06 #1
14 2144
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

Jan 24 '06 #2

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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.

Jan 24 '06 #3
Angel Tsankov wrote:
"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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

Jan 24 '06 #4

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Angel Tsankov wrote:
"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.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.

Jan 24 '06 #5
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

Jan 24 '06 #6

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.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.

Jan 24 '06 #7
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::stringstream) that
best suits that platform.

Cheers! --M

Jan 24 '06 #8

"mlimber" <ml*****@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.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.

Jan 24 '06 #9
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

Jan 24 '06 #10

"mlimber" <ml*****@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
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.


This exactly is the problem - my class cannot have a default ctor. A
default ctor is needed to create an array of objects of a UDT. So, if
I adopt your plan then I cannot have an array of objects of my class.

Jan 24 '06 #11
Angel Tsankov wrote:
"mlimber" <ml*****@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Angel Tsankov wrote:
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.


This exactly is the problem - my class cannot have a default ctor. A
default ctor is needed to create an array of objects of a UDT. So, if
I adopt your plan then I cannot have an array of objects of my class.


OIC. I read your previous post to mean that your class *shouldn't* have
a default constructor. Sorry.

There are several ways to get around that problem. One is to use a
std::vector rather than arrays (which are evil) so that you can choose
a different constructor. See this FAQ:

http://www.parashift.com/c++-faq-lit....html#faq-10.5

Another is to use a static member variable to point to the log that can
be used for all objects of each class. The log could be set at the
declaration and/or via a static member function, .e.g.:

class MyClass
{
static boost::shared_ptr<ostream> log_;
public:
static SetLog( boost::shared_ptr<ostream>& log )
{
log_ = log;
}
};

Finally, you could use a (global) singleton log object. See chapter 6
of _Modern C++ Design_ for copious detail on how to implement such a
singleton to meet different needs. A simple version might look like:

template<class T>
class Singleton
{
public:
static T& Instance();
private:
// Disabled functions (no bodies provided)
Singleton();
Singleton( const Singleton& );
Singleton& operator=( const Singleton& );
Singleton* operator&();
~Singleton();
};

template<class T>
T& Singleton<T>::Instance()
{
static T myObject;
return myObject;
}

// Assume class Log is defined somewhere
typedef Singleton<Log> theLog;

class MyClass
{
public:
// ...
~MyClass() { theLog::Instance() << "MyClass destroyed."; }
};

Also, see these FAQs for why you shouldn't use arrays polymorphically:

http://www.parashift.com/c++-faq-lit....html#faq-21.4
http://www.parashift.com/c++-faq-lit....html#faq-21.5

Cheers! --M

Jan 24 '06 #12
Angel Tsankov wrote:
Can anyone think of some other way to use the assert macro for
verification?
What about any other options?


This article might interest you:
http://www.cuj.com/documents/s=8464/...p0308alexandr/
Martin

--
Quidquid latine scriptum sit, altum viditur.
Jan 25 '06 #13

"Martin Eisenberg" <ma**************@udo.edu> wrote in message
news:11***************@ostenberg.wh.uni-dortmund.de...
Angel Tsankov wrote:
Can anyone think of some other way to use the assert macro for
verification?
What about any other options?


This article might interest you:
http://www.cuj.com/documents/s=8464/...p0308alexandr/


Yes, it did. Thanks!

Jan 25 '06 #14

"Angel Tsankov" <fn*****@fmi.uni-sofia.bg> wrote in message
news:43***********************@news.sunsite.dk...
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.


However, code that tests NDEBUG for specific values has undefined
behavior (doesn't it?) and should be avoided. Therefore, it should be
OK to use the #undef-#define trick with NDEBUG, right?

Jan 25 '06 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Eyal | last post by:
Hi, We have an issue with Debug Assertion showing in Release builds in Managed C++! I have created a small managed C++ project that looks like this: #include "stdafx.h" #using <mscorlib.dll>...
5
by: InstallAware | last post by:
For Press Inquiries: Sinan Karaca InstallAware Software Corporation 336 Guerrero Street, San Francisco CA 94103 415 358 4094 (voice/fax) sinank@installaware.com http://www.installaware.com/ ...
12
by: Vasco Lohrenscheit | last post by:
Hi, I have a Problem with unmanaged exception. In the debug build it works fine to catch unmanaged c++ exceptions from other dlls with //managed code: try { //the form loads unmanaged dlls...
5
by: David++ | last post by:
Hi there, I have built a DLL in Visual C++ 6. When I build the DLL it builds fine for the debug version of the DLL (and this DLL works fine), however, I seem unable to build a Release version of...
3
by: Steve Franks | last post by:
I'm using Visual Studio 2005 RC and cannot figure out how to produce a "release" build. Am I doing something wrong? I'm wondering if perhaps MS locked out the ability to produce a release build...
2
by: saju.prabhakaran | last post by:
Hi, I have an application in C++ which will report stack report. iam getting the report file in Debug mode. But when i build the apps in relaese mode , iam not getting the expected report. Pl...
1
by: kurt sune | last post by:
I am having trouble publishing a website for RELEASE. 1. web.config: <compilation defaultLanguage="vb" debug="false"> 2. in Configuration manager I set the configuration to Release for the...
6
by: Andrew Rowley | last post by:
I am having trouble getting debug and release builds to work properly with project references using C++ .NET and Visual Studio 2003. I created a test solution, with a basic Windows form C++...
0
by: Duncan Smith | last post by:
Last week, I got reports back of errors in a patch I let someone try out (release dll, but not from the build machine). Turns out it was some Debug::Assert statements firing. In umanaged code,...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.