On 23.09.2015 17:52, Auer, Jens wrote:
i can only invite those people who experience these warnings to contribute patches to silence them: if warning-free headers are important for your project, it is best to test new boost versions early (maybe even checkouts of the develop branch) and submit pull requests to the specific libraries before they are released ...
Without a general consensus on warning handling policy, this would become a sysiphus job. Let's say I fix the warnings which currently represent problems in my project. During the development of the next release, other people commit new code with new warnings, or may even change the fixes to emit new warnings. I think there needs be general policy that code should not introduce new warnings, and that changed code is warning free.
IMO, trying to be warning-free on the multitude compilers Boost supports is what can be called a sysiphus job. Not only this is tedious and practically inachievable, it actually makes the code worse - typically, in terms of maintainability, sometimes performance. Striving for no warnings at the highest levels gives false sense of purity but really nothing more than that. But, if you're really interested in keeping Boost warning-free, you should put some effort into it. Run tests regularly, monitor changes, submit pull requests. Nothing is going to change unless someone interested acts.