Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:44 PM, Kenny Riddile<kfriddile@yahoo.com> wrote:
Emil Dotchevski wrote:
I think that warnings must be fixed when the needed work is not huge. It will be great if Boost defined which warning must be fixed and which ones are allowed. When a warning is allowed and not fixed a comment on the line could help users to know if the warning is know (will not be fixed) or if it is a new one. In this way the author will compare the effort to fix it or add the comment. I disagree. Warnings are a personal conversation between the compiler and the author of the code. They are nobody else's business.
That statement seems to conflict with your argument against fixing/silencing warnings in library code. For example, I am not the author of Boost.Exception, therefore any warnings emitted by it are none of my business. According to what you just said, the only person who should ever see warnings emitted by Boost.Exception is you.
Yes, so don't look at any warnings in Boost.Exception :P
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
If that was an option, I would certainly follow that advice :) Unfortunately, when sifting through warnings emitted by code of which I AM the author, warnings from library code will inevitably scroll across my screen, be projected onto my retinas, and become my "business" whether I like it or not. Then there's also the fairly common case of warnings-as-errors/highest-warning-level which needs no explanation. What you're suggesting simply isn't possible. A fair alternative would be to have a list of acceptable warnings (assignment operator could not be generated, etc.), and mandate that no other warnings be emitted by Boost libraries on supported compilers.