-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] 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