On 7/18/2014 3:03 PM, Mostafa wrote:
On Fri, 18 Jul 2014 06:47:55 -0700, Edward Diener
wrote: On 7/18/2014 7:50 AM, Bjørn Roald wrote: [snip]
I am thinking it may be time to be less gentle on new none compliant compiler versions. Why don't Boost attempt to remind Boost users and their compiler vendors that there are underlying non compliant compiler and standard library issues, in this case with the MS header files and preprocessor, that is complicating the availability, maintenance and improvement of the Boost libraries. One slightly radical but perhaps effective method would be to provide custom diagnostics, e.g. compiler warning and errors as appropriate. triggered by work around macros in Boost. The diagnostics should have a direct link to a page on Boost Wiki (or similar) that states the purpose of the diagnostics. Then state the status related to the goals of the Wiki page and suggested actions to take by users to help. The Wiki page should state how it is possible to silence the compiler warnings, but encourage users to take suggested actions before silencing the diagnostics.
[snip]
A separate diagnostic library based on macros could work to do this. But we should of course allow the end-user to turn on or off such compiler diagnostics messages.
Should it? I thought the whole point is to sufficiently bug users so that they put enough pressure on their compiler vendors to become standards conformant.
Bugging users for any reason is not my idea of good software. All that it may do is antagonize users, and what is the good of that.