Dear all, I've started a wiki page here: https://svn.boost.org/trac/boost/wiki/WarningFixes for folks to collaborate on fixing warnings from Boost libraries. As noted the initial effort should be directed towards core libraries - those that get included and reused by other libraries. You can help by: * Running the tests for your favorite libraries (those not already listed, or with "unknown" status), and updating their "Status" field to reflect whether any work is needed. * Filing bug reports if it's not obvious how to silence the warnings. * Filing patches if the fixes are obvious. * Fixing the code if you're a library author! There's something for everyone there, whether you're a Boost newbie, or a hardened veteran, so I hope that many hands can make light work of this! Cheers, John.
Hmmm - at what level are the tests run at? That is if using msvc at warning level 3 and it comes up "clean" but that doesn't happen at level 4, it the library "clean". For gcc - I don't know if there is a concept of warning level or if there is something analogous. But there certain warnings can be suppressed, and there is -weff and -pedantic etc. Exactly what is the hoop we're expected to jump through? Robert Ramey John Maddock wrote:
Currently I have /W4 for msvc, and /Wall /Wextra -pedantic for gcc listed on the wiki page. That's the starting point. There are some things that just can't be made clean at that level - that's fine - just log the fact on the wiki so folks don't waste their time on it (for example, I couldn't find a way to zero-initialize an aligned_storage that was portable and that gcc didn't complain about: try building type_traits/aligned_storage_test.cpp to see what I mean). Think of those warning levels as an *aspiration* and lets see how it goes.
Exactly what is the hoop we're expected to jump through?
Hopefully no hoops :-) OK so I haven't looked at many libraries yet (and not serialization I admit), but so far in testing mostly my stuff plus Test/Utility/Integer the needed fixes look trivial where they're needed at all. If those flags are just too onerous for some library X, then we can reconsider. Frankly we won't know until we try. Also the initial emphasis should be on those "core" Boost libraries that often get reused by the rest of Boost. "Terminal" libraries that aren't reused within Boost can mostly look after themselves. Not sure which category serialization is in though ;-) Regards, John.
John Maddock wrote:
Currently I have /W4 for msvc, and /Wall /Wextra -pedantic for gcc listed on the wiki page.
I thought the serialization library was "clean" until someone complained that there were warnings at level 4. When I investigated, I found that the major complaint was that that I had "const" members so the compiler couldn't generate copy/assigment functions. It turns out that these classes used the boost::noncopyable facility. So to eliminate these warnings this facility needs to be re-implemented in a different way. It sort of an illustration how an idea with the the best of intentions leads to seems to lead to a host of unanticipated consequences. (Hmmm reminds me of current political events - maybe I watch to much TV). Bottom line, I'm stuck in a box. Robert Ramey
Sigh... I forgot about that one: it's hit me before as well :-( It seems that any implementation of non_copyable will inevitably generate this warning with msvc - unless we rewrote it as a helper macro that you use at class scope to define those private members - but that's hardly much help either as it sort of defeats the whole "self documenting" purpose of non_copyable. So I think the only solution is to use #pragma's in that case: in case you're not familiar with them the usual incantation is: #ifdef BOOST_MSVC #pragma warning(push) #pragma warning(disable: number-list) #endif // Code goes here #ifdef BOOST_MSVC #pragma warning(pop) #endif Where "number-list" is a whitespace separated list of all the warnings to suppress. HTH, John.
Robert Ramey wrote:
While not as easy for you as some yet undiscovered change to noncopyable, can't you just use the MSVC pragma warning dance around your classes to quiet that warning in each case? _____ 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:
I could, and I might but.... To my mind this is an invalid warning. The code in question is not incorrect and the boost::noncopyable provides the protection against the situation that the warning is designed to detect. So from my perspective the best would be to add /wd4511 and /wd4512 to the compiler switches. Of course that's not really a good solution because other code might not have the boost non_copyable protection. Ideally the compiler would be able detect that the copy/assigment functions can't be used in this case any way. Or maybe the compiler needs some sort of class attribute. in the meantime... Of course I can conditionaly include pragma for this compiler. The problem is that you start have to doing for all compilers and they've all got their own set of quirks. This makes the code harder to read, understand and maintain. You HAVE to do it sometimes to work around bogus compiler errors but I'm sort of reluctant to embark upon this to work around bogus compiler warnings. This raises the question about how to handle the "warning" that such and such a function has been "deprecated" when it actually hasn't and of course those warnings which are just hints that sometimes have to be knowingly violated. Basically, once you start considering this - it sort of takes on a life of its own. Robert Ramey
On Mon, Nov 9, 2009 at 3:39 PM, Robert Ramey <ramey@rrsd.com> wrote:
At that point, isn't it less work to just declare the copy c-tor and the assignment operator private? The MSDN documentation says that this will silence the warning. I guess it would have been nice of them to look in base classes as well when considering this warning...
I think the proper way to deal with those warnings is documentation that states that Boost libraries may emit those warnings unless _CRT_SECURE_NO_WARNINGS _SCL_SECURE_NO_WARNINGS are defined. C++ didn't deprecate those functions, Microsoft did, so it's no longer Boost's concern. --Michael Fawcett
Nod. I think this is a common issue: the warning is entirely bogus in this case, but in other contexts users may find it genuinely useful. The question is whether we can silence the "noise" to a level that allows the user to turn on a higher level of warnings and get useful output from their code only. In this case yes, I believe we can.
Nod. I don't think anyone is suggesting that all of boost be warning free with all possible compilers, that just wouldn't be possible IMO. But does that mean that we shouldn't try to do better with the most popular tools? Not a rhetorical question, just feeling my way yours.... John.
On Tue, Nov 10, 2009 at 1:58 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Nod. I don't think anyone is suggesting that all of boost be warning free with all possible compilers, that just wouldn't be possible IMO.
It is possible. For me, the bottom line from this discussion is that #pragma warning and #pragma GCC system_header are my best friends. :)
But does that mean that we shouldn't try to do better with the most popular tools?
I think first we need to figure out what's the goal of removing warnings: is it to impose higher warning level to developers, or to provide warning-free user experience. If it is the former, I find it inappropriate to cherrypick some warnings *we* consider silly and tell the user, you know what, we're not doing anything about these particular ones, gg. If I work at a company that requires warning-free builds, one warning is one warning too many. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Nov 10, 2009 at 7:33 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
Sorry for getting in this late, but with gcc, isn't it better to just include boost code with --isystem instead of -I? I usually never see warnings from boost because I use the boost version that comes with the linux distro I use, which puts all headers in /usr/include. Gcc treats all headers there as system headers and doesn't show any warning. If I have to use of a boost installation in a non-standard include path, I make sure to use -isystem if I do not want to see warning. IMHO, with gcc at least, boost should just document that the preferred way to include boost headers, if not installed by default, is through -isystem, which has the double advantage of not polluting boost headers with compiler specific workarounds and still giving the user full control of whether he wants to see warnings or not. just my 2 eurocents, -- gpd
Giovanni Piero Deretta wrote:
Sorry for getting in this late, but with gcc, isn't it better to just include boost code with --isystem instead of -I?
Does that suppress warnings related to user-supplied template parameters causing untoward behavior in Boost templates? Using static_cast, for example, is surgical in nature, whereas --isystem is systemic. Put another way, will using --isystem quiet too much? _____ 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, Nov 10, 2009 at 11:32 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
It depends on the definition of too much. One possible definition is that as long as using Boost doesn't hide more warnings than using STL, it isn't too much. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Nov 10, 2009 at 10:33 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
I meant latter, not former. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Sun, Nov 8, 2009 at 10:38 AM, Robert Ramey <ramey@rrsd.com> wrote:
warnings=all in the appropriate jamfile defaults?
Shouldn't the default on each individual compiler be the default? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil, I have no idea how this is going to go. My gut feeling is that since I fairly often get bug reports files against my stuff if it emits any warnings at all even at the very highest levels the compiler supports, then we should at least *try* to support that if it's practical to do so. Only one way to find out if it's practical I'm afraid... John.
No - I don't think it should - because Boost is aiming to be as Portable and C++ Standard compliant as possible. What *users* chose is entirely their choice - and the default for their compiler would be entirely sensible. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Do you mean in the Jamfile that declares the tests for that library? Ultimately this is probably a good idea - but in the short term even libraries that are marked as "clean" often generate a minor blizzard of warnings from their dependencies - often only the same warning over and over, but this is probably not such a good idea until we've reduced the warnings from the "core" libraries a bit. Regards, John.
And there are some HOW-To suggestions on warnings at https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines at the end of the document. Managing Warnings from Compilers (and other tools) Avoid warnings, Eliminate warning, Suppress Warnings, or Document. including copy'n'paste examples that may save you some time. Paul PS There two documents might be merged? --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On Sun, 8 Nov 2009, John Maddock wrote:
Would it be possible to get the warning output from the regression tests, at least for libs/{graph,property_map,graph_parallel}? I do not believe I have easy access to the compilers that are going to be used for warning checking. -- Jeremiah Willcock
participants (9)
-
Emil Dotchevski -
Giovanni Piero Deretta -
Jeremiah Willcock -
John Maddock -
Michael Fawcett -
Paul A. Bristow -
Robert Ramey -
Sascha Ochsenknecht -
Stewart, Robert