Re: [Boost-users] Wave: how to recover after errors?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-12-09 15:57:35

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Max 
> Motovilov

> > The question is: what is reasonable?
> 
> At risk of repeating myself ;-) I'll say -- whatever most 
> C/C++ preprocessors do by default or can be coaxed into doing 
> by command-line options is probably reasonable. While you 
> state Wave's primary purpose as being a benchmark for 
> standard-conformal preprocessor functionality, I still 
> suspect that most practical uses will require it to work with 
> existing code.

The solution is to fix existing code, not break the preprocessor.

> And if some bad practices prevail in the existing code, the 
> tool maker often has to provide an option of supporting them 
> in some way, just to make his tool more useful.

If bad practices in the form of undefined or ill-formed code exist in some code,
then the implementation should reject that code.  There is nothing good about
preserving defects--even if they keep people from having to update code.  All it
does is propogate bad code forever. 

> Note how 
> Micro$oft still preserves an option for non-conformant 
> visibility of loop control variable names (even though they 
> finally changed the default to OFF in 8.0).

...and the option shouldn't even exist.  If code will not build on a new
implementation, fix the code or compile it on the old implementation.

> > AFAIU compilers normally do not recover from errors in the 
> sense that 
> > they try to correct them.

> public to private at a certain point in time). I'd say that 
> ability to re-define macro names falls squarely within that 

You can legally redefine macro names:

#undef MACRO
#define MACRO ...

> 1% -- from the times when I was actively concurrently working 
> with a large number of C++ compilers on various platforms, I 
> can't remember a single one that would fully prohibit the 
> practice or produced different results. There may not be all 
> that many of those "accepted errors"
> at preprocessor level, but being able to support them appears 
> to be a clear plus...

IMO, it is clear negative.  It is in users' best interest and the interest of
the community as a whole for implementations to reject any translation unit that
contains code that either introduces undefined behavior or is ill-formed.  It is
not always reasonable to diagnose the former, but it is always reasonable to
diagnose the latter.  Anything less than that encourages writing bad code.  In
nearly every case, the fixes to the code are simple.  The fixes required are
numerous, but they are one-time fixes, and you don't even have to search for
them--the implementation should point them out to you.

Regards,
Paul Mensonides