[warnings] Are warnings acceptable artifacts from builds?
Just curious, when I use certain libraries, I get compiler warnings. Are these simply acceptable during a build, or should they be reported to somebody ? The latest warning I'm seeing are: Warning 4 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 377 Warning 5 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 400 Regards, -Sid Sacek
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them. Robert Ramey Sid Sacek wrote:
Just curious, when I use certain libraries, I get compiler warnings.
Are these simply acceptable during a build, or should they be reported to somebody ?
The latest warning I'm seeing are:
Warning 4 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 377 Warning 5 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 400
Regards, -Sid Sacek
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
Using casts doesn't hide warnings so much as tell the compiler that you have examined the context and want it to convert something anyway. Leaving warnings is worse than using a cast because library users are left to wonder whether there are problems in the library, can't find their own warnings and errors among your warnings, and can't build when they prefer to treat warnings as errors. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
Using casts doesn't hide warnings so much as tell the compiler that you have examined the context and want it to convert something anyway.
Leaving warnings is worse than using a cast because library users are left to wonder whether there are problems in the library, can't find their own warnings and errors among your warnings, and can't build when they prefer to treat warnings as errors.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of vi ruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I couldn't agree more.
On Tue, Sep 8, 2009 at 12:51 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
Using casts doesn't hide warnings so much as tell the compiler that you have examined the context and want it to convert something anyway.
Leaving warnings is worse than using a cast because library users are left to wonder whether there are problems in the library, can't find their own warnings and errors among your warnings, and can't build when they prefer to treat warnings as errors.
Warnings may indicate a problem with your own code but in anyone else's code they should be ignored. Insisting to fix warnings is somewhat insulting to the author of the library, too. It presumes that they did something unreasonable, when in fact the warning itself may be unreasonable. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 12:51 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
Using casts doesn't hide warnings so much as tell the compiler that you have examined the context and want it to convert something anyway.
Leaving warnings is worse than using a cast because library users are left to wonder whether there are problems in the library, can't find their own warnings and errors among your warnings, and can't build when they prefer to treat warnings as errors.
Warnings may indicate a problem with your own code but in anyone else's code they should be ignored.
Unfortunately, compilers don't distinguish yours from theirs, so that doesn't work. It also doesn't solve the problem for those that prefer to treat warnings as errors.
Insisting to fix warnings is somewhat insulting to the author of the library, too. It presumes that they did something unreasonable, when in fact the warning itself may be unreasonable.
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning. If nothing works, then a comment at the warning site will educate the library user. Those that treat warnings as errors may then choose to do something drastic in their environment that the library author would be unwilling to do, but it is better to avoid that altogether. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Sep 8, 2009 at 1:11 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
Warnings may indicate a problem with your own code but in anyone else's code they should be ignored.
Unfortunately, compilers don't distinguish yours from theirs, so that doesn't work. It also doesn't solve the problem for those that prefer to treat warnings as errors.
It also doesn't solve the problem of those who prefer to shoot themselves in the foot. :)
Insisting to fix warnings is somewhat insulting to the author of the library, too. It presumes that they did something unreasonable, when in fact the warning itself may be unreasonable.
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning.
Why? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:11 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
Insisting to fix warnings is somewhat insulting to the author of the library, too. It presumes that they did something unreasonable, when in fact the warning itself may be unreasonable.
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning.
Why?
For the reasons I already gave. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Sep 8, 2009 at 1:27 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:11 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
Insisting to fix warnings is somewhat insulting to the author of the library, too. It presumes that they did something unreasonable, when in fact the warning itself may be unreasonable.
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning.
Why?
For the reasons I already gave.
To address someone's preference? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:27 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:11 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning.
Why?
For the reasons I already gave.
To address someone's preference?
Come now. I gave more reasons than that one. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Sep 8, 2009 at 1:59 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:27 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:11 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning.
Why?
For the reasons I already gave.
To address someone's preference?
Come now. I gave more reasons than that one.
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed. But you can't generalize from this, to "all warnings should be silenced." Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Sep 8, 2009 at 2:18 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed.
But you can't generalize from this, to "all warnings should be silenced."
On the other hand, many people work in environments where there is a local policy that warnings will be treated as errors. If library code emits warnings, the build breaks and the library is unusable. The local policy may be unreasonable, but it still hurts the usability of a library to have warnings. I agree that some compilers will warn for reasons that seem not worth the trouble it takes to eliminate them in the code, but by not taking the trouble it potentially eliminates a class of users from taking advantage of the library authors hard work. That said, I'd be interested in an example of a warning not worth fixing. I haven't worked with the more draconian compilers in a long time, and it'd be educational to have a concrete counter-example to compare against. Christopher
On Tue, Sep 8, 2009 at 4:24 PM, Christopher Currie<christopher@currie.com> wrote:
On Tue, Sep 8, 2009 at 2:18 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed.
But you can't generalize from this, to "all warnings should be silenced."
On the other hand, many people work in environments where there is a local policy that warnings will be treated as errors. If library code emits warnings, the build breaks and the library is unusable.
I agree this is a very strong argument, and you're right that even though such policy is unreasonable, it may render a library basically unusable. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 4:24 PM, Christopher Currie<christopher@currie.com> wrote:
On Tue, Sep 8, 2009 at 2:18 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed.
But you can't generalize from this, to "all warnings should be silenced."
On the other hand, many people work in environments where there is a local policy that warnings will be treated as errors. If library code emits warnings, the build breaks and the library is unusable.
I agree this is a very strong argument, and you're right that even though such policy is unreasonable, it may render a library basically unusable.
Why is such policy unreasonable? Suppose that building a source file that uses Boost libraries produces 100 warnings from Boost code. Can you suggest a reasonable strategy how a developer can spot the warnings in their own code amids the pages of warnings from Boost? For bonus points, assume that Boost is not installed system-wide, but is included in the project, possibly with local tweaks. - Volodya
On Tue, Sep 8, 2009 at 11:13 PM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 4:24 PM, Christopher Currie<christopher@currie.com> wrote:
On Tue, Sep 8, 2009 at 2:18 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed.
But you can't generalize from this, to "all warnings should be silenced."
On the other hand, many people work in environments where there is a local policy that warnings will be treated as errors. If library code emits warnings, the build breaks and the library is unusable.
I agree this is a very strong argument, and you're right that even though such policy is unreasonable, it may render a library basically unusable.
Why is such policy unreasonable?
I think you misunderstood my point. What I called unreasonable in the text you're quoting is environments (e.g. companies people use Boost at) where there is a requirement to treat warnings as errors. So I was agreeing that the existence of such environments--unreasonable as they are--is a strong argument for zero-warning policy in Boost. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 11:13 PM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 4:24 PM, Christopher Currie<christopher@currie.com> wrote:
On Tue, Sep 8, 2009 at 2:18 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed.
But you can't generalize from this, to "all warnings should be silenced."
On the other hand, many people work in environments where there is a local policy that warnings will be treated as errors. If library code emits warnings, the build breaks and the library is unusable.
I agree this is a very strong argument, and you're right that even though such policy is unreasonable, it may render a library basically unusable.
Why is such policy unreasonable?
I think you misunderstood my point. What I called unreasonable in the text you're quoting is environments (e.g. companies people use Boost at) where there is a requirement to treat warnings as errors.
Well, because there's no other reasonable way to make new warnings in code to be noticed and examined, I think that warnings-as-errors is actually a reasonable requirement.
So I was agreeing that the existence of such environments--unreasonable as they are--is a strong argument for zero-warning policy in Boost.
This conclusion I do agree with. - Volodya
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:59 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:27 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:11 PM, Stewart, Robert<Robert.Stewart@sig.com> wrote:
The warning may, in fact, be unreasonable, but the library author should do all possible to quiet the warning.
Why?
For the reasons I already gave.
To address someone's preference?
Come now. I gave more reasons than that one.
I think that you assume that the warning is reasonable and easy to fix, as with most warnings that could be silenced with casts. A lot of times, fixing such warnings is common sense. In that case, just a note to the library developer would be enough to have it fixed.
But you can't generalize from this, to "all warnings should be silenced."
I never did that, though you seem intent upon imposing that view upon me. Go back and reread my earlier posts. You'll see that I said to remove all warnings possible. I know that not all can be removed. I also know that most can be. Your arguments have been adversarial from the start, claiming that those with my view are being rude to you, the library developer, whose code shouldn't be questioned. (Review your own posts to see why I would say so.) The goal should be to eliminate every warning possible because a library's warnings should not obscure a library user's warnings and errors, because the warnings connote inferior library code quality to the user (I'd think library developers would wish to avoid such connotations), and because there are many that treat warnings as errors. If warnings cannot be avoided, then they should be documented and the library user must deal with such warnings as best they can. That doesn't change the goal. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Hi, ----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Tuesday, September 08, 2009 9:51 PM Subject: Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
Using casts doesn't hide warnings so much as tell the compiler that you have examined the context and want it to convert something anyway.
Leaving warnings is worse than using a cast because library users are left to wonder whether there are problems in the library, can't find their own warnings and errors among your warnings, and can't build when they prefer to treat warnings as errors.
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. For example, when a variable is not used it is simpler to remove the variable than adding a comment. Vicente
On Tue, Sep 8, 2009 at 1:14 PM, vicente.botet<vicente.botet@wanadoo.fr> 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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Sep 8, 2009 at 4:31 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
On Tue, Sep 8, 2009 at 1:14 PM, vicente.botet<vicente.botet@wanadoo.fr> 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.
Frankly, after just having reviewed (by using) a library that spit out 60+ warnings resulting in hundreds of kilobytes worth of warning messages, I have to disagree. Those warnings become my business when I have to wade through them just to find the bloody error message. --Michael Fawcett
On Tue, Sep 8, 2009 at 1:36 PM, Michael Fawcett<michael.fawcett@gmail.com> wrote:
On Tue, Sep 8, 2009 at 4:31 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
On Tue, Sep 8, 2009 at 1:14 PM, vicente.botet<vicente.botet@wanadoo.fr> 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.
Frankly, after just having reviewed (by using) a library that spit out 60+ warnings resulting in hundreds of kilobytes worth of warning messages, I have to disagree. Those warnings become my business when I have to wade through them just to find the bloody error message.
I agree that warnings are annoying; the problem is that a compiler may choose to warn about anything at all, this is not subject to any specifications. What if a compiler warns about lines being longer than 80 characters? I'd think that most would agree that such a warning is unreasonable. So the question is whether a warning is reasonable or not, which is subjective. Requiring warnings to be fixed is the same as requiring the library developer to agree with your own subjectively picked warnings level. I find that rather rude (it's not unreasonable to ask politely, of course.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:36 PM, Michael Fawcett<michael.fawcett@gmail.com> wrote:
On Tue, Sep 8, 2009 at 4:31 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
On Tue, Sep 8, 2009 at 1:14 PM, vicente.botet<vicente.botet@wanadoo.fr> 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. Frankly, after just having reviewed (by using) a library that spit out 60+ warnings resulting in hundreds of kilobytes worth of warning messages, I have to disagree. Those warnings become my business when I have to wade through them just to find the bloody error message.
I agree that warnings are annoying; the problem is that a compiler may choose to warn about anything at all, this is not subject to any specifications. What if a compiler warns about lines being longer than 80 characters? I'd think that most would agree that such a warning is unreasonable.
So the question is whether a warning is reasonable or not, which is subjective. Requiring warnings to be fixed is the same as requiring the library developer to agree with your own subjectively picked warnings level. I find that rather rude (it's not unreasonable to ask politely, of course.)
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
Boost has certain coding standards does it not? How is this different than agreeing on acceptable and unacceptable warnings on supported compilers?
On Tue, Sep 8, 2009 at 2:12 PM, Kenny Riddile<kfriddile@yahoo.com> wrote:
Boost has certain coding standards does it not? How is this different than agreeing on acceptable and unacceptable warnings on supported compilers?
Sure, the guidelines can be extended, I'm all for reaching an agreement. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:36 PM, Michael Fawcett<michael.fawcett@gmail.com> wrote:
On Tue, Sep 8, 2009 at 4:31 PM, Emil Dotchevski<emildotchevski@gmail.com> wrote:
On Tue, Sep 8, 2009 at 1:14 PM, vicente.botet<vicente.botet@wanadoo.fr> 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.
Frankly, after just having reviewed (by using) a library that spit out 60+ warnings resulting in hundreds of kilobytes worth of warning messages, I have to disagree. Those warnings become my business when I have to wade through them just to find the bloody error message.
I agree that warnings are annoying; the problem is that a compiler may choose to warn about anything at all, this is not subject to any specifications. What if a compiler warns about lines being longer than 80 characters? I'd think that most would agree that such a warning is unreasonable.
You've picked a wrong example. If such code is part of Boost, then it's in violation of library guidelines: http://www.boost.org/development/requirements.html - Volodya
On Tue, Sep 8, 2009 at 11:06 PM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
I agree that warnings are annoying; the problem is that a compiler may choose to warn about anything at all, this is not subject to any specifications. What if a compiler warns about lines being longer than 80 characters? I'd think that most would agree that such a warning is unreasonable.
You've picked a wrong example. If such code is part of Boost, then it's in violation of library guidelines:
You got me here. :) Honestly, I don't know if my code violates that guideline, because it turns out secretly I'm already violating another guideline: I don't use fixed width font when coding. :)) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 11:06 PM, Vladimir Prus<vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
I agree that warnings are annoying; the problem is that a compiler may choose to warn about anything at all, this is not subject to any specifications. What if a compiler warns about lines being longer than 80 characters? I'd think that most would agree that such a warning is unreasonable.
You've picked a wrong example. If such code is part of Boost, then it's in violation of library guidelines:
You got me here. :)
Honestly, I don't know if my code violates that guideline,
This suggest that the inspect program should be adjusted :-P
because it turns out secretly I'm already violating another guideline: I don't use fixed width font when coding. :))
Heh. I frankly never understood what this guideline means, unless we plan to require that new libraries have their source code printed in a book and sent for review by snail mail. - Volodya
On Wed, 09 Sep 2009 10:54:03 +0400, Vladimir Prus <vladimir@codesourcery.com> wrote:
Heh. I frankly never understood what this guideline means, unless we plan to require that new libraries have their source code printed in a book and sent for review by snail mail.
I really think this requirement should go as well. Maybe not allow 200 chars per line, put 80 chars per line is too strict. Must the ride side of our screen stay black till the end of times? -- EA
Edouard A. wrote:
On Wed, 09 Sep 2009 10:54:03 +0400, Vladimir Prus <vladimir@codesourcery.com> wrote:
Heh. I frankly never understood what this guideline means, unless we plan to require that new libraries have their source code printed in a book and sent for review by snail mail.
I really think this requirement should go as well. Maybe not allow 200 chars per line, put 80 chars per line is too strict.
Must the ride side of our screen stay black till the end of times?
I think it should stay blank only until your favourite editor or IDE gets split view functionality ;-) - Volodya
On Wed, 09 Sep 2009 11:07:05 +0400, Vladimir Prus <vladimir@codesourcery.com> wrote:
I think it should stay blank only until your favourite editor or IDE gets split view functionality ;-)
I need open spaces to feel inspired... Freedom... Riding the motorbikes around the wild side of the IDE... :D But seriously, 80 chars is too short. I understand not everyone has got a 30" inches display, but I'm sure we can widen things a bit, or can't we? -- EA
Edouard A. wrote:
On Wed, 09 Sep 2009 11:07:05 +0400, Vladimir Prus <vladimir@codesourcery.com> wrote:
I think it should stay blank only until your favourite editor or IDE gets split view functionality ;-)
I need open spaces to feel inspired... Freedom... Riding the motorbikes around the wild side of the IDE... :D
But seriously, 80 chars is too short. I understand not everyone has got a 30" inches display, but I'm sure we can widen things a bit, or can't we?
I think we're drifting away from the original topic of this thread. If you are working on a prospective Boost library and the 80-character requirement is a serious impediment to your progress, can you post a separate message about that? Thanks, Volodya
Edouard A. wrote:
On Wed, 09 Sep 2009 10:54:03 +0400, Vladimir Prus <vladimir@codesourcery.com> wrote:
Heh. I frankly never understood what this guideline means, unless we plan to require that new libraries have their source code printed in a book and sent for review by snail mail.
I really think this requirement should go as well.
BTW, I was talking about fixed font requirement above. The 80-character requirement seems reasonable to me and certainly the *meaning* of that requirement is clear. - Volodya
Edouard A.
Maybe not allow 200 chars per line, put 80 chars per line is too strict.
Must the ride side of our screen stay black till the end of times?
I regularly code with two-up emacs buffers, 80 columns each. That approach also permits me to print source code -- which I do not infrequently -- without hard to follow line breaks. Consequently, I like the 80 column limit and am frustrated by code that exceeds that limit. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Michael Fawcett wrote:
Frankly, after just having reviewed (by using) a library that spit out 60+ warnings resulting in hundreds of kilobytes worth of warning messages, I have to disagree. Those warnings become my business when I have to wade through them just to find the bloody error message.
I have also reviewed that library. There were far too many warnings, but some of the warnings really were nonsense (in the sense that fixing the compiler would be more reasonable than trying to work around the warnings). Thomas Klimpel wrote:
- It is true that msvc-9 spits out many warnings. However, it is also true that "warning C4127: conditional expression is constant" for a code like template <typename value_type, typename geometry_type_1, typename geometry_type_2, int op_type> void execute_boolean_op(value_type& output_, const geometry_type_1& lvalue_, const geometry_type_2& rvalue_, ... if(op_type < 2) is nonsense, because op_type is a template parameter. So I have the impression that the only way to get rid of the msvc warnings is by disabling the nonsense warnings with appropriate pragmas.
I don't know what about the boost way to silence warnings, but if it is along the line of #ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif ... #ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif then silencing 60+ warnings in this way will add 420+ lines to the source code. Regards, Thomas
On Tue, Sep 8, 2009 at 7:26 PM, Thomas Klimpel<Thomas.Klimpel@synopsys.com> wrote:
Thomas Klimpel wrote:
- It is true that msvc-9 spits out many warnings. However, it is also true that "warning C4127: conditional expression is constant" for a code like template <typename value_type, typename geometry_type_1, typename geometry_type_2, int op_type> void execute_boolean_op(value_type& output_, const geometry_type_1& lvalue_, const geometry_type_2& rvalue_, ... if(op_type < 2) is nonsense, because op_type is a template parameter. So I have the impression that the only way to get rid of the msvc warnings is by disabling the nonsense warnings with appropriate pragmas.
Well, it's right. That's a constant conditional expression. You can either ignore the warning or put it in a template specialization which would get rid of the warning. Is it defined in the standard that the conditional will *always* get optimized away? If it isn't, that seems like a reasonable warning.
I don't know what about the boost way to silence warnings, but if it is along the line of
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif
...
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif
then silencing 60+ warnings in this way will add 420+ lines to the source code.
I don't think that works with templates. Typically to silence errors in template code, the user must put those pragmas around the point of instantiation. The warnings I saw were int->bool, bool->int conversions, unused parameters, and struct now seen as class. I agree some warnings are nonsense, but there are some cases (just mentioned) that should be silenced by proper code changes. I don't think a strict "no warning" policy needs to be in place, which I think is what Emil is against, but I think Boost should strive to have as few as possible and there's too much low hanging fruit waiting to be picked currently (causing lots of noise). --Michael Fawcett
Michael Fawcett wrote:
Well, it's right. That's a constant conditional expression.
You're trying to tease me, right?
You can either ignore the warning or put it in a template specialization which would get rid of the warning. Is it defined in the standard that the conditional will *always* get optimized away? If it isn't, that seems like a reasonable warning.
MSVC explicitly says whether a warning is just a performance warning, and C4127 is not a performance warning. It is a warning to inform the programmer about a possible mistake (IIRC, if(true) or if(false) don't trigger this warning). I don't understand what you mean by "... or put it in a template specialization which would get rid of the warning". Are you suggesting I should try to emulate the optimizer of the compiler, even if this would imply substantial code duplication?
I don't know what about the boost way to silence warnings, but if it is along the line of
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif
...
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif
then silencing 60+ warnings in this way will add 420+ lines to the source code.
I don't think that works with templates. Typically to silence errors in template code, the user must put those pragmas around the point of instantiation.
I hope you're joking.
The warnings I saw were int->bool, bool->int conversions, unused parameters, and struct now seen as class.
I agree some warnings are nonsense, but there are some cases (just mentioned) that should be silenced by proper code changes.
Agreed.
I don't think a strict "no warning" policy needs to be in place, which I think is what Emil is against, but I think Boost should strive to have as few as possible and there's too much low hanging fruit waiting to be picked currently (causing lots of noise).
Agreed. I just tried to give a concrete example to Christopher Currie's request: "That said, I'd be interested in an example of a warning not worth fixing. I haven't worked with the more draconian compilers in a long time, and it'd be educational to have a concrete counter-example to compare against." Regards, Thomas
AMDG Thomas Klimpel wrote:
Michael Fawcett wrote:
You can either ignore the warning or put it in a template specialization which would get rid of the warning. Is it defined in the standard that the conditional will *always* get optimized away? If it isn't, that seems like a reasonable warning.
MSVC explicitly says whether a warning is just a performance warning, and C4127 is not a performance warning. It is a warning to inform the programmer about a possible mistake (IIRC, if(true) or if(false) don't trigger this warning).
But while(true) does trigger it. (which is really annoying.)
I don't think that works with templates. Typically to silence errors in template code, the user must put those pragmas around the point of instantiation.
I hope you're joking.
For msvc, warnings need to be suppressed around the point of definition. In Christ, Steven Watanabe
On Tue, Sep 8, 2009 at 8:19 PM, Thomas Klimpel<Thomas.Klimpel@synopsys.com> wrote:
Michael Fawcett wrote:
Well, it's right. That's a constant conditional expression.
You're trying to tease me, right?
No, sorry if I came off that way.
You can either ignore the warning or put it in a template specialization which would get rid of the warning. Is it defined in the standard that the conditional will *always* get optimized away? If it isn't, that seems like a reasonable warning.
MSVC explicitly says whether a warning is just a performance warning, and C4127 is not a performance warning. It is a warning to inform the programmer about a possible mistake (IIRC, if(true) or if(false) don't trigger this warning). I don't understand what you mean by "... or put it in a template specialization which would get rid of the warning". Are you suggesting I should try to emulate the optimizer of the compiler, even if this would imply substantial code duplication?
I agree it's annoying. I'm curious (in the sense that I have no clue what the answer is)...does MSVC generate the code in the else block when it gives that warning?
I don't think that works with templates. Typically to silence errors in template code, the user must put those pragmas around the point of instantiation.
I hope you're joking.
I wish. That's how it works with MSVC though.
The warnings I saw were int->bool, bool->int conversions, unused parameters, and struct now seen as class.
I agree some warnings are nonsense, but there are some cases (just mentioned) that should be silenced by proper code changes.
Agreed.
I don't think a strict "no warning" policy needs to be in place, which I think is what Emil is against, but I think Boost should strive to have as few as possible and there's too much low hanging fruit waiting to be picked currently (causing lots of noise).
Agreed.
I think everyone can agree that Boost should strive for as few warnings as possible, but forcing all libraries to be warning free on all compilers is close to impossible. --Michael Fawcett
AMDG Michael Fawcett wrote:
On Tue, Sep 8, 2009 at 8:19 PM, Thomas Klimpel<Thomas.Klimpel@synopsys.com> wrote:
I don't think that works with templates. Typically to silence errors in template code, the user must put those pragmas around the point of instantiation.
I hope you're joking.
I wish. That's how it works with MSVC though.
No it doesn't. At least, not in recent versions. The following produces a warning only if I leave the initial #define. #define WARNINGS #ifndef WARNINGS #pragma warning(push) #pragma warning(disable:4244) #endif template<class T> char f(T t) { return t; } #ifndef WARNINGS #pragma warning(pop) #endif int main() { f(1); } In Christ, Steven Watanabe
On Tue, Sep 8, 2009 at 11:26 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Michael Fawcett wrote:
I wish. That's how it works with MSVC though.
No it doesn't. At least, not in recent versions. The following produces a warning only if I leave the initial #define.
<snip> I just tried that - you're right (and I'd be a fool to argue with you about templates). However, I have seen warnings produced by templates in Boost code that do not get suppressed using that technique. The only way to suppress them was to use those pragmas in my own files, but I have no such evidence that I can present without quite a bit of time searching. So I guess the point is moot. --Michael Fawcett
On Wed, Sep 9, 2009 at 11:08 AM, Michael Fawcett <michael.fawcett@gmail.com> wrote:
On Tue, Sep 8, 2009 at 11:26 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Michael Fawcett wrote:
I wish. That's how it works with MSVC though.
No it doesn't. At least, not in recent versions. The following produces a warning only if I leave the initial #define.
<snip>
I just tried that - you're right (and I'd be a fool to argue with you about templates).
However, I have seen warnings produced by templates in Boost code that do not get suppressed using that technique. The only way to suppress them was to use those pragmas in my own files, but I have no such evidence that I can present without quite a bit of time searching. So I guess the point is moot.
I finally remembered what I was thinking about. The warnings were from a boost header, but it was not surrounded by pragmas. That caused me to have to surround every include of that header with those pragmas, eventually causing me to just make a new header that did that. So my memory completely failed me. Sorry, Thomas and Steven. Regards, --Michael Fawcett
Michael Fawcett wrote:
On Tue, Sep 8, 2009 at 7:26 PM, Thomas Klimpel<Thomas.Klimpel@synopsys.com> wrote:
Thomas Klimpel wrote:
- It is true that msvc-9 spits out many warnings. However, it is also true that "warning C4127: conditional expression is constant" for a code like template <typename value_type, typename geometry_type_1, typename geometry_type_2, int op_type> void execute_boolean_op(value_type& output_, const geometry_type_1& lvalue_, const geometry_type_2& rvalue_, ... if(op_type < 2) is nonsense, because op_type is a template parameter. So I have the impression that the only way to get rid of the msvc warnings is by disabling the nonsense warnings with appropriate pragmas.
Well, it's right. That's a constant conditional expression. You can either ignore the warning or put it in a template specialization which would get rid of the warning. Is it defined in the standard that the conditional will *always* get optimized away? If it isn't, that seems like a reasonable warning.
It seems to me that the compiler could be warning about the constant for one of two good reasons, though it is certainly possible that the warning is bogus. First, it could be alerting you that there's a likely mistake in your code. It is helpful to know that what you thought would be a real conditional turns out to not be so, which permits you to correct your code. Not bad. Second, it could be warning you that the conditional will not be optimized away, thus informing you that your code is less efficient than it could be. The latter may not be accurate; inspecting the assembly output will prove the optimizer's prowess. It is wise to strive to eliminate all warnings because they cause a second look at the code to be sure it does what's expected and because it is helpful to the library user. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Tue, Sep 8, 2009 at 4:26 PM, Thomas Klimpel<Thomas.Klimpel@synopsys.com> wrote:
I don't know what about the boost way to silence warnings, but if it is along the line of
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif
...
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif
then silencing 60+ warnings in this way will add 420+ lines to the source code.
Unfortunately many compilers have no such features. IMHO the best way to address warnings is not to disable them globally, but to be able to tag a section of code as "pls to disable warning X for this code kthx" but that's also not widely available, AFAIK. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Thomas Klimpel wrote:
Michael Fawcett wrote:
Frankly, after just having reviewed (by using) a library that spit out 60+ warnings resulting in hundreds of kilobytes worth of warning messages, I have to disagree. Those warnings become my business when I have to wade through them just to find the bloody error message.
I have also reviewed that library. There were far too many warnings, but some of the warnings really were nonsense (in the sense that fixing the compiler would be more reasonable than trying to work around the warnings).
Which is the more likely? Even if you could see the compiler fixed, it will only help those users that use the newer version.
Thomas Klimpel wrote:
- It is true that msvc-9 spits out many warnings. However, it is also true that "warning C4127: conditional expression is constant" for a code like template <typename value_type, typename geometry_type_1, typename geometry_type_2, int op_type> void execute_boolean_op(value_type& output_, const geometry_type_1& lvalue_, const geometry_type_2& rvalue_, ... if(op_type < 2) is nonsense, because op_type is a template parameter. So I have the impression that the only way to get rid of the msvc warnings is by disabling the nonsense warnings with appropriate pragmas.
I don't know what about the boost way to silence warnings, but if it is along the line of
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif
...
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif
Those could easily be macros, thus reducing the source code burden. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
AMDG Stewart, Robert wrote:
Thomas Klimpel wrote:
I don't know what about the boost way to silence warnings, but if it is along the line of
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif
...
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif
Those could easily be macros, thus reducing the source code burden.
I'd be interested to see how. The best way of handling it that I'm familiar with is #include <boost/library/detail/disable_warnings.hpp> #include <boost/library/detail/enable_warnings.hpp> In Christ, Steven Watanabe
Steven Watanabe wrote:
Stewart, Robert wrote:
Thomas Klimpel wrote:
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(push) #pragma warning(disable:4127) #endif
...
#ifdef BOOST_WARNING_MSVC_WORKAROUND #pragma warning(pop) #endif
Those could easily be macros, thus reducing the source code burden.
I'd be interested to see how. The best way of handling it that I'm familiar with is
#include <boost/library/detail/disable_warnings.hpp>
#include <boost/library/detail/enable_warnings.hpp>
Hmmm, my preprocessor skills are not great (a good thing!), so I probably spoke out of turn. I should just leave things like that to someone like Paul Mensonides. Still, a library could create a pair of headers and include them around the suppression regions, thus reducing the source code burden as I thought a macro could. I believe a macro can be used to generate a filename for an include directive, so different warnings could be suppressed using a generalized pattern, right? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Emil Dotchevski wrote:
On Tue, Sep 8, 2009 at 1:14 PM, vicente.botet<vicente.botet@wanadoo.fr> 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.
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
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.
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
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.
Stewart, Robert wrote:
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
Using casts doesn't hide warnings so much as tell the compiler that you have examined the context and want it to convert something anyway.
Leaving warnings is worse than using a cast because library users are left to wonder whether there are problems in the library, can't find their own warnings and errors among your warnings, and can't build when they prefer to treat warnings as errors.
I'm not really unsympathetic to such a point of view. The problem is that when you make a library which spans say - 8 compilers, it becomes alot more work to try to quiet them all that it would first appear. Naturally with production code for one or two compilers you don't see this. Remember the boost library code is filled with #ifdef's and such to deal with all the small quirks and differences between compilers. Trying to suppress all warnings for all compilers IS a lot of work. Of course I'm not refering to simple/universal cases like replacing f(int x) with f(int /*x*/) for an unused x - many libraries already do this. consider the case where T x; ... int y = x; where on one platform T is a char, another it's an unsigned char, on another it's an int, and on another it's unsigned int. (This is actually the case for wchar_t !). Addressing this can take a lot of time and headache without really improving the library in anyway. Please let's not spend a whole lot of time on this particular example - I needed a fast one for this email - if this one is not a good example - its just because I didn't want to spend a lot more time looking. Robert Ramey
Robert Ramey wrote:
warnings vary with compilers. It's a huge amount of extra work to eliminate all warnings in all compilers. And in many cases "fixing" warnings really amounts to "hiding" warnings (e.g. using a cast) so "fixing" them is worse than leaving them.
I think this is rather sloppy position, and the current pile of warnings produced when building Boost clearly gives a negative light to otherwise high-quality library. Note all that eliminating all warnings in all compilers is not required -- release tests are run with a few compilers, basically msvc and gcc. Surely, promising no warnings for a compiler that is not even tested would be too much, but promising no warnings for the few officially supported compilers seems like reasonable approach. - Volodya
Sid Sacek wrote:
Just curious, when I use certain libraries, I get compiler warnings.
Are these simply acceptable during a build, or should they be reported to somebody ?
The latest warning I'm seeing are:
Warning 4 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 377 Warning 5 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 400
I suggest you file a bug. You can also provide a patch, since the fix is easy.
I've never logged a bug before. Where do I do that? Thanks, -Sid -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard
I suggest you file a bug. You can also provide a patch, since the fix is easy.
AMDG Sid Sacek wrote:
I've never logged a bug before. Where do I do that?
Use the trac at http://svn.boost.org/ In Christ, Steven Watanabe
participants (13)
-
Christopher Currie -
Edouard A. -
Emil Dotchevski -
Kenny Riddile -
Mathias Gaunard -
Michael Fawcett -
Robert Ramey -
Sid Sacek -
Steven Watanabe -
Stewart, Robert -
Thomas Klimpel -
vicente.botet -
Vladimir Prus