🚀 go-pugleaf

In article <49j043$2ga@engnews1.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>
>Any compiler may have any pragmas it wants. IMHO, pragmas should not
>be specified in the standard, since they are by definition outside
>the language, affecting only implemenation details, or changing
>language semantics from what the standard says.  

That reminds me, there is something else that badly needs fixing.

Any #pragma that is not recognized and supported by an implementation
_must_ generate a diagnostic!  A pragma that had some important meaning
when the code was written should not be silently ignored when some new
compiler doesn't spell it the same way.  This is just plain wrong. 

This would present no problems in code that is ported between different
compilers if pragmas were properly guarded using symbols that identify the
compiler, ie.: 

    #ifdef __BOGUSC__
    #pragma pack(1)
    #else
    #error portability problem
    #endif

But the compiler's behavior of ignoring bad pragmas means that nobody does
this.  
 
Likewise, the documentation on pragmas for one compiler I use is very
poor.  How do you debug pragmas, when a misspelled pragma option generates
no diagnostic, and no detectable change in the compiler output?  Took me
hours to figure some of them out. 

How many pragmas are in your code that do nothing?  How do you know? 

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]