On Sat, Aug 21, 2010 at 6:09 AM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Fri, Aug 20, 2010 at 9:33 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Fri, Aug 20, 2010 at 5:13 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Fri, Aug 20, 2010 at 1:02 PM, Robert Ramey <ramey@rrsd.com> wrote:
Jeff Flinn wrote: > By the way Robert, thanks for clearing up all of the compiler > warnings in both the lib and in portable_binary_archive over the > last couple of releases.
I'm glad you appreciate this. I caused an unintended ripple effect which resulted in much agony - which is likely not over..
advice to prospective library developer's - use warning level 4 it's cheaper in the long run.
#pragma warning(push,1) on MSVC, and #pragma gcc system_header are cheaper.
hmmm - please expand upon this.
I'm not sure if this is a good idea in general but I'm using this in Boost Exception and I'm not aware of any problems it causes. I have
#if defined(__GNUC__) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma GCC system_header #endif #if defined(_MSC_VER) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma warning(push,1) #endif
at the top of the header files (and the matching pop for MSVC at the end of the file), so when I build the code I can use whatever warning level is comfortable for me (combined with #define BOOST_EXCEPTION_ENABLE_WARNINGS), while everyone else doesn't see any warnings (I hope.)
Of course that is a moot point if you like warning level 4 or the --pedantic stuff in GCC, but I find it very difficult to justify many of the things (for example, casts) people normally do to work around warnings.
When I read you're response, I was thinking it was another way to enable maximum warnings. If I understand you correctly, your view is that the warnings should be suppressed even when users enable higher levels.
So it seems we've got entirely opposed points of view here.
Personally, I found that the excercise of modifying code to eliminate warnings at the level resulted in eliminating a couple of potential bugs and hopefully maintaining this will keep new ones from creeping it. I will concede that some warnings are over the top and I would like a better way (in GCC) to suppress them on a case by case basis.
I agree with you 100%. I wish there was a way to *suppress* a warning without altering the semantics of the program. But in GCC, there isn't. So the question is what to do with those pesky warnings that you think are over the top yet users of the library find useful?
One option is to "fix" them anyway. Unfortunately, a lot of times this involves casting, and in general I find it ill-advised to use a cast to suppress a warning. Think about it: casts are used to tell the compiler to do something it wouldn't normally do because it is dangerous. This is true for all casts, including the ones people sprinkle around to "fix" warnings.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
I am not any expert in this field but very interested. We try and use high warning levels and attempt to ensure people implement true fixes where possible and not code around warnings, such as doing something to 'use an unused parameter' etc. In the case you mention about casts, is the case not that the warning is telling you the compiler thinks it knows what you want but is not sure, so clarify with a cast or alter your code to do something the compiler can understand better (which is the preferred route I imagine)? There always seems to be debates against warnings that are spurious but I am of the opinion coding to try and let the compiler understand what you are doing and using warnings as check would be good practice. There are many debatable warnings which surely can be handled with small changes. So if there is 2 ways to do something (there is always much more) and the compiler complains about one way, why not then code the other way (in a lot of cases, not all, I do understand some of the debates). I sometimes wonder if we take high ground on these issues too quickly when giving a little may help a lot. A good example is some of the destructor not declared virtual in a base class type stuff, huge debates and both sides can prove they are correct, however the compiler still emits the warnings. If you have a clean build and a warning appears then great, if you already have tones you ignore you probably wont see the new problem so easily and warnings become less useful. I repeat, no expert but interested.