Customized assert question...

Actually it really isnt that big of a deal, but i was just wondering if anyone happen to see a problem or insecurity with my assert setup. I don't like the regular assert.

Code:

//required for MessageBoxA() functions
#include <windows.h>
//required to use std::stringstream
#include <sstream>

//Check if program is debug build
#ifndef NDEBUG

//Assign the asert macro
#ifdef assert
#undef assert
#endif

#if defined(BOX)
#define assert Wassert
#elif defined(CONSOLE)
#define assert Cassert
#else
#define assert assert
#endif

#if defined(BOX)
#define createBox \
struct create \
    {\
create(const int& line, const char* file, const char* message)\
{\
std::stringstream ss;\
const char* title = "Assertion Error!!!";\
ss << "!!!Assertion Error!!!\nFile: " << file << "\nLine: " << line << "\n\n" << message;\
MessageBoxA(NULL,ss.str().c_str(),title, 0);\
};\
    } myboxmaker = create
#endif

//
#ifdef CONSOLE
#define Cassert \
    if ( false ) {} else struct LocalAssert { \
    int mLine; \
    LocalAssert(int line=__LINE__) : mLine(line) {} \
    LocalAssert(bool isOK, char const *message="", bool quit = false) { \
    if ( !isOK ) { \
    (void)printf("ERROR!! Assert failed on " \
    "line %d in file\n-->%s\n%s\n", \
    LocalAssert().mLine, __FILE__, message); \
    if (quit) \
       abort();\
    else\
    __asm { int 3 } \
    } \
}\
    }myAsserter = LocalAssert
#endif

//checks if Wassert is to be used
#ifdef BOX
#define Wassert \
    if ( false ) {} else struct LocalAssert { \
    int mLine; \
    LocalAssert(int line=__LINE__) : mLine(line) {} \
    LocalAssert(bool isOK, char const *message="", bool quit = false) { \
    if ( !isOK ) { \
    createBox(LocalAssert().mLine, __FILE__, message);\
    if (quit) \
    abort();\
    else\
    __asm { int 3 } \
    } \
}\
    }myAsserter = LocalAssert
#endif

#ifndef BOX
#ifndef CONSOLE
#define assert \
    if ( true ) {} else struct NoAssert { \
    NoAssert(bool isOK, char const *message="", bool quit = false) {} \
    } myAsserter = NoAssert
#endif
#endif

#endif

Well thanks, and maybe someone else will be able to use this as well.

I suggest you make them into functions instead of macros. It will be much easier to spot and fix errors if you do.

I can really help Raigne. I get an headache trying to read macro definitions. But one thing I did notice however is that you probably could #ifdef that windows.h include to cut on compilation times

My personal opinion would be that you define a SHORT macro that does the actual assertion (if (condition) do_assert(line, file, #cond), and then call a function that does the actual "show message and stop".

This is something I just hacked up right now:

Code:

// myassert.h
void domyassert(const char *msg, int line, const char *file);

#define myassert(x) do { if (!(x)) domyassert(#x, __FILE__, __LINE__); } while(0)


// myassert.c:
#include <stdio.h>

void domyassert(const char *msg, const char *file, int line)
{
	fprintf(stderr, "Assert failed: %s at %s:%d\n", msg, file, line);
	__asm int 3;
}

You may of course want to have two different versions of "domyassert", depending on whether you do "Windows" or "Console" mode programs. If you don't want to have myassert.c as part of your project, you are probably going to use an #if solution in the header file and implement two different domyassert functions.

The problem with your solution is that it creates a new function every single time you add an assert() in the code, which means that you end up with a LOT of extra code. The above code adds about 15 bytes per assert . Your code most likely adds a whole

I take it your "if (false) ; else" is a different way to tackle the "do { ... } while (0)" standard way to ensure that a complex macro can be used as a simple C statement. Why not use "do ... while (0)" like everyone else?

--
Mats

hmm, ill clean it all up with the suggestions mentioned and repost.

I came up with this for my assert. It does look alot better.

Code:

#pragma once

//Check if program is debug build
#ifndef NDEBUG

void __assert_win32_(const char* message, const char* file, const int& line); 
void __assert_console_(const char* message, const char* file, const int& line);

#if defined(WIN32_ASSERT)
#define assert(x) do { if (!x) { __assert_win32_(#x, __FILE__, __LINE__); } } while(0);
#elif defined(CONSOLE_ASSERT)
#define assert(x) do { if (!x) { __assert_console_(#x, __FILE__, __LINE__); } } while(0);
#endif

#endif

and the implementation of the functions is

Code:

#include "myassert.h"

void __assert_win32_(const char* message, const char* file, const int& line)
{
	std::stringstream ss;
	ss << "Assertion Error: \nFile: " << file << "\nLine: " << line << "\n\nVariable: " << message;
	MessageBoxA(NULL, ss.str().c_str(), "!!!ASSERT ERROR!!!", NULL);
	__asm { int 3 }
}

void __assert_console_(const char* message, const char* file, const int& line)
{
	printf("Error Variable: &#37;s\nFile: %s\nLine: %d",message, file, line);
	__asm { int 3 }
}

Hope this will help someone.

Why the #pragma once? And why the double underscores? And how important is the assembly part?

The assembly part fires up the debugger, if any is installed. A better way would be to call Win32's DebugBreak().

The double underscores are unacceptable, though.

I believe the #pragma part is a MS-ism to avoid include guards - I prefer the traditional approach of using include-guards, but that's just me.

As CornedBee says, the __asm int 3 is a "breakpoint trap", so if you have a debugger on the machine, you can fall straight into the debugger.

I agree, the double underscores are reserved for "compiler implementation", and just to make sure you don't clash, you should use your own variant to ensure your names are unique enough.

--
Mats

I thought it was single underscore prefix for the compiler, and the assembly is to actually trigger a breakpoint, but unlike the abort() function which does the same thing it does not terminate the program at the assert call. if that makes any sense.

Everything starting with an underscore is for the compiler. A single underscore is reserved for global identifiers, meaning you may give locals, class members and elements within namespaces such names, but not top-level globals, constants of top-level enums, or macros. And I'd advise against the allowed cases, too.
A double underscore or an underscore followed by an upper-case letter is completely reserved. The compiler may define macros, extension keywords and whatever else it wants with such names, thus making them unsafe to use for you in any context.