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 32,744 of 33,346    |
|    DeMarcus to All    |
|    Wouldn't it be good to refactor __LINE__    |
|    16 Dec 12 19:48:31    |
   
   From: use_my_alias_here_at_hotmail_com@tellus.orb.dotsrc.org   
      
   Hi,   
      
   There's at least one place where I can't get rid of macros; that is when   
   using __LINE__ and __FILE__. At the places where I need such debug   
   information I usually want as much information as possible, and writing   
   std::cout << __FILE__ << ":" << __func__ << ":" << __LINE__ <<   
   std::endl; everywhere is a lot of clutter.   
      
   I propose the following to be standardized:   
      
   namespace std   
   {   
      
   struct line_info   
   {   
    const char* file_name; // similar to __FILE__   
    const char* function_name; // similar to __func__   
    const uint32_t line_number; // similar to __LINE__   
      
    // ... possible other parameters that could be of use in a   
    // future stack trace functionality.   
   };   
      
   } // namespace std   
      
   To be used like this:   
      
   myLineInfoPrinter( std::linfo );   
      
   where std::linfo is a line_info struct constant that the compiler   
   creates at the spot, just like __LINE__.   
      
   We have already standardized __FILE__ and __LINE__ so this struct   
   wouldn't be too problematic I guess, and it would be nice to remove yet   
   another macro from the code.   
      
   What do you think about my idea?   
      
      
   Regards,   
   Daniel   
      
      
   --   
    [ 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