Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 31,755 of 33,346    |
|    Martin Ba to DeMarcus    |
|    Re: Are MACROS good and can the compiler    |
|    20 Dec 11 12:14:56    |
   
   From: 0xcdcdcdcd@gmx.at   
      
   DeMarcus Wrote:   
   > I don't like macros.   
   > The worst thing I know is macros spread all over the code like:   
   >   
   > DEBUG_PRINT("Some text");   
   >   
      
   Why? Seriously. I fail to see the problem with a well-named, well-   
   behaved macro, *if it offers something your suite of complers doesn't   
   offer otherwise*. And there are - sadly - still too many of these.   
      
   > I still see one benefit with macros; you can remove code completely.   
   >   
   > Therefore I was thinking of the following solution:   
   >   
   > inline void debugPrint( const std::string& text )   
   > {   
   > #ifndef NDEBUG   
   > std::cout << text << std::endl;   
   > #endif   
   > }   
   > ...   
   > My question is; if NDEBUG is set, is it common behavior that the   
   > compiler will see that debugPrint() is empty and then remove the   
   > function call completely so I get the same removal behavior as a macro?   
   >   
      
   Iff the compiler does the inlining, then there will be no code to be inlined   
   and there won't be any code generated. However, you cannot portably be sure   
   if inlining happended, or if your compiler had a funny idea and still put   
   the function call in. (On MSVC you could use __forceinline.)   
      
   cheers,   
   Martin   
      
      
   --   
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
    [ comp.lang.c++.moderated. First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca