49864727   
   From: akfmnews@t-online.de   
      
   >> Or, optionally, they should be more flexible, so that they could replace   
   >> code generators.   
      
   "Mathias Gaunard"  wrote   
      
   >They usually can, most people just don't know how to use them.   
      
   Hm, a comparable statement would be: Usually all C++ code can be written by   
   using C or assembly language,   
   people just don't know how to use assembly language.   
   Or I could state: In most cases where macros are used, Boost MPL can be   
   used. Most people just don't know how   
   to use this library.   
   Or: Commonly macros are used to simulate missing language features (e.g.   
   variadic templates)   
      
   Yes, so far you are correct, alternatively macros can be used in many cases,   
   where code generators are used.   
   But that wasn't my point:   
      
   - Macros prevent the compiler to be as fast in compilation as compilers of   
   other languages. Because each   
     header file as to be compiled again and again and again. C++ compilers   
   generate highly efficient code,   
     but in contrast the compiler itself can't be that efficient regarding   
   compilation speed   
      
   - Macros pollute the global namespace. Each header file propagates it's   
   macros to all code   
     which includes this header file. Yes, macros can be undefined, but there's   
   no   
     "LOCAL" keyword in the language which does that automatically or it's not   
   possible   
      
   - Macros don't support namespaces.   
      
   - Macros are hard to debug. If macros expand to a huge piece of code, you   
   can't simply step into the code   
     or see which line of code caused a crash when analyzing a crash dump   
      
   - Macros have the same problem as templates: You can't see the generated   
   code (WYSWIG) easily and   
     IDE code completion is limited, compared to "normal code"   
      
   - An invalid macro in a header file can cause hours of happy debugging, if   
   the compiler isn't smart enough to   
     point you to the error source, e.g. as the clang compiler. Anyways, if the   
   macro expands to valid but wrong   
     code it's hard to find the error, since you can't see the expanded code   
   directly.   
     Just in contrast to code generators, where you can debug and see the   
   expanded code.   
      
   Macros have the advantage to be built into the "language" (preprocessor).   
   But IMHO this doesn't outweigh   
   the disadvantages.   
      
   Andre   
      
      
      
      
      
      
   --   
         [ 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)