From: use_my_alias_here_at_hotmail_com@tellus.orb.dotsrc.org   
      
   >> 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.   
   >   
      
   Unfortunately I'm too inexperienced with the implementations of   
   preprocessors and compilers. I took a wild guess that since the compiler   
   can output errors with file name, function and line number, it may also   
   be able to substitute the internals of the line_info struct.   
      
   But for sure, the whole idea with std::linfo is that it should avoid the   
   preprocessor.   
      
      
   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)