From: daniel.kruegler@googlemail.com   
      
   On 2012-12-17 04:48, DeMarcus wrote:   
   > 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__   
      
   I consider a type like uint32_t as problematic, because it is not   
   guaranteed to exist for all systems. If you insist on some minimum   
   size-constraints, I suggest to use uint_least32_t instead.   
      
   >    // ... 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?   
      
   I like the general idea, but I would like to see implementation   
   experience of the proposal. Your idea bases on a mixture of current   
   preprocessor concepts and high-language concepts and I would like to   
   know about the impact on existing preprocessor implementations. At the   
   current moment exists no library component with such a strong binding   
   between these different worlds and all existing emulations of what you   
   describe above finally end up in involving explicit usage of a macro.   
   Obviously, std::linfo cannot be such a macro.   
      
   - 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)