How overload a define macro?

This is a discussion on How overload a define macro? within the C++ Programming forums, part of the General Programming Boards category; Can i do something like this: Code: #define check( obj ) \ ...elided... \ #define check...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    184

    How overload a define macro?

    Can i do something like this:

    Code:
    #define check( obj )      \
       ...elided...           \
    
    #define check

  2. #2
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    No. You must first undefine check by using #undef check.
    Then it is legal to redefine it.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,414
    Out of curiosity, 6tr6tr, have you read Stroustrup's answer to the FAQ: So, what's wrong with using macros? ?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    Registered User
    Join Date
    Nov 2006
    Posts
    184
    Quote Originally Posted by laserlight View Post
    Out of curiosity, 6tr6tr, have you read Stroustrup's answer to the FAQ: So, what's wrong with using macros? ?
    Yep.

  5. #5
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    You can overload a macro at compile time. I do it for debug and release versions of a custom assert and a debug print macro.

    Code:
    void __assert__(const char * file, unsigned line, bool dump);
    
    #ifdef DEBUG
    #define DEBUG_PRT(args) std::printf args 
    #define ASSERT(expr) if (!(expr)) __assert__(__FILE__, __LINE__, true); 
    #else 
    #define DEBUG_PRT(args)
    #define ASSERT(expr) if (!(expr)) __assert__(__FILE__, __LINE__, false); 
    #endif

  6. #6
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,169
    O_O

    You... you keep the assert?

    Soma

  7. #7
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    It could possibly log an error, too, rather than just throwing an assert.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #8
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by phantomotap View Post
    O_O

    You... you keep the assert?

    Soma
    No, I keep the custom __assert__ function.

    Code:
    void __assert__(const char * file, unsigned line, bool dump)
    {
       	std::fprintf(stderr, "Assertion failed at line %u in file %s\n", line, file);
       	std::fflush(NULL);
       	if (dump) std::abort();
    }

  9. #9
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Among the reasons mentioned here for keeping an assert in the code is this:
    Another reason for keeping asserts in the ship version of an embedded product is that turning the asserts off will change the timing characteristics of the program. On a desktop application, this rarely leads to a different end result. In real-time applications, removing the asserts may lead to misbehavior that did not arise before-and the assertions will not be in place to detect the situation. It's also worth bearing in mind that on the desktop, more speed is always better, while on embedded products, extra speed is often not an advantage, once you meet your hard real-time targets.
    FWIW
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  10. #10
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,169
    No, I keep the custom __assert__ function.
    Same. Difference. (I was only asking if you kept the assert; not for the particulars of the implementation. I don't care if it 'abort's of not.)

    Still... I think I'm in love. First person I ever met that has the good sense to keep an assert in release builds.

    Soma

  11. #11
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I am with Dave on this one sometimes. The timing issue actually has arisen for me a time or two, but that isn't always my only justification. I am heavy into using asserts in fundamental levels of a program, i.e. memory management. I personally would rather a program die during various critical errors via assert rather than more or less write my own equivalent to assert in order to accomplish the task of aborting safely.

    On the flip-side, on non-fundamental levels of a program (such as rendering to the screen) I think its best practice for it not to be compiled into a release version.

  12. #12
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by phantomotap View Post
    Still... I think I'm in love. First person I ever met that has the good sense to keep an assert in release builds.
    I'm not sure if this is sarcasm, but assuming it isn't, I'm one of the followers of that school of thought as well.

    Having the asserts get compiled in only for debug, encourages you to do final testing in debug configuration. This is, of course, a tragically wrong thing to do. When you test in debug, then recompile for release, and don't repeat all of your testing again, what you have essentially done is released a completely untested binary.

    You might attempt to argue that if the assert didn't get triggered in debug, it wouldn't be triggered in release, but that naively ignores the fact that bug behavior can change dramatically when moving to release mode.

    So, you either have to give up the concept of asserts altogether, or you have to leave them in the release build. I choose the second option...

  13. #13
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,169
    I'm not sure if this is sarcasm, but assuming it isn't, I'm one of the followers of that school of thought as well.
    Nope. Not sarcasm. (Well, not entirely. ^_^)

    Beyond what you, and the other guys, have pointed out, I've just rarely seen the things used in ways that they can safely be removed from release builds. (That is to say, I usually see 'std::assert' used in code that has side effects that must remain in release builds for the code to perform correctly.)

    Naturally, being me, I try to avoid them in favor of compile-time firewalls, but when I do use my form of assert, which either throws a complex exception that supports "appended" types and information or 'abort's outright, the only difference between debug and release builds is where the debug information is presented by default--debug console versus a file dump.

    Soma

  14. #14
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by brewbuck View Post
    This is, of course, a tragically wrong thing to do. When you test in debug, then recompile for release, and don't repeat all of your testing again, what you have essentially done is released a completely untested binary.
    I don't do debug builds unless I'm, well, debugging. All unit testing and QA is done on the release build

  15. #15
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I guess now we should really consider the fact of when assert() should be used. When debugging real-time code on a pc, I do use them during development just to protect me against idiotic errors that take forever to debug. i.e.

    Code:
    void drawObject(object *x)
    {
       assert(x);
       assert(x->image); // etc.
       ...
    }
    To be honest, its a widely under used debugging tool that truly does protect against tiny errors that keep us up at night.


    So at this point I agree with you entirely brewbuck. Now for the part where I tip my hat to Dave's logic. assert() is handy for embedded devices as he pointed out, but not only that, its handy for security protocols too. One can make assertions about what someone is doing, and ultimately just kill the program instead of allowing a serious attack to be performed. Or in less doomsday-ish scenarios, you'd be amazed at how nice it is to get feedback from an end-user relevant to why a program is giving them trouble instead of just getting a couple emails saying "The program seems to crash very rarely, and I think it has something to do with when I open a help file."

    Just some thoughts. Feel free to argue the merits of my commentary.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Help me with function call
    By NeMewSys in forum C++ Programming
    Replies: 16
    Last Post: 05-22-2008, 01:53 PM
  2. C Programming 2d Array Question
    By jeev2005 in forum C Programming
    Replies: 3
    Last Post: 04-26-2006, 03:18 PM
  3. whats wrong here
    By sreetvert83 in forum C++ Programming
    Replies: 15
    Last Post: 09-21-2005, 10:05 AM
  4. Error check problem again
    By rtransfi in forum C Programming
    Replies: 6
    Last Post: 02-27-2003, 03:55 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21