On 01/11/2011 02:14 AM, Paul A. Bristow wrote: ... elisions are all by patrick ...
Of course!
Thanks for this - please do not hesitate to update the wiki with this valuable information. I have already for some of it, but I've just gotten enough information to complete it, which I will do very soon. I'll also put in a set of macros inspired by ones by Jonathan Wakely that make using this stuff a lot prettier. I'll announce here when all the information is complete and correct. You might like to enquire of GCC if there is a limit on the number of push'n'pops - as we discovered with MSVC (which severely limits its usefulness as with Boost libraries it would be easy to exceed the limit (about 50). This limit increases the desirability of dealing the cause of the warnings, rather than silencing them). I finally read the source (a nice thing we can do with gcc), and found out that nested pushes are only limited by memory, since the diagnostic stack and the diagnostic_history array are xrealloc'd (the libiberty version of realloc that prints an error message to stderr and exits on memory exhaustion), on each push or pop, as appropriate, and by MAXINT since int indices are used to indicate the next spot on the stack and history. (Why don't people use unsigned int for things that are always 0 and greater? Sure cuts down on the signed vs. unsigned comparison warnings, sometimes gets rid of hard to find bugs, and is more elegant. Why not say what you mean?)
I also checked to see what happens on an extra unbalanced pop and was pleased to see that it is meaningful and not harmful in that if nothing is on the diagnostic stack the options as set by the command line are merely reasserted.
Paul
PS We have little or no information about other platforms. Are spurious warnings a non-issue with them? Well, this page of the wiki (https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines), is about much more than spurious warnings. It has good information about what warnings mean and how to deal with them. Much of the time with gcc at least, the warnings point to real problems in the code. Less of the time it's a condition that _may_ indicate something wrong but in your case is not, and the smallest, (but non empty) case is bugs in gcc. The main point of the document is that you should get rid of all of your warnings by rewriting the code if at all possible, since:
o It's likely to improve your code making it more elegant and correct o It will find bugs that will surprise you o When meaningful warnings arise in the future they won't be lost in the noise o Companies that do not allow code that generates warnings will use boost (although on gcc, -i is useful in this case because it makes a directory in the include path considered to contain only system files and warnings are not issued for anything in them). o People don't assume you're a sloppy careless programmer The document ends with: *Intel* Information needed here. *Darwin /MacOS* Information needed here. *ACC* Information needed here. *Borland* Information needed here. So, you can see that there's a lot of opportunity for people that know about these compilers. best regards, Patrick