Help needed in fixing warnings

[John Maddock]

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey]

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:

> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

> 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.

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey]

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey]

John Maddock wrote:
> 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.
>

Looking at the page, wouldn't it make sense to include

warnings=all

in the appropriate jamfile defaults?

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Emil Dotchevski-3]

On Sun, Nov 8, 2009 at 10:38 AM, Robert Ramey <ramey@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>> 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.

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>> 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.
>>
>
> Looking at the page, wouldn't it make sense to include
>
> warnings=all
>
> in the appropriate jamfile defaults?

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>> warnings=all
>> in the appropriate jamfile defaults?
>
> Shouldn't the default on each individual compiler be the default?

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul A. Bristow-2]

> -----Original Message-----
> From: boost-bounces@... [mailto:boost-bounces@...] On
Behalf Of

> John Maddock
> Sent: Sunday, November 08, 2009 5:32 PM
> To: boost@...
> Subject: [boost] Help needed in fixing warnings
>
> 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!

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
[phone], mobile [phone]
pbristow@...





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul A. Bristow-2]

> -----Original Message-----
> From: boost-bounces@... [mailto:boost-bounces@...] On
Behalf Of

> Emil Dotchevski
> Sent: Sunday, November 08, 2009 6:58 PM
> To: boost@...
> Subject: Re: [boost] Help needed in fixing warnings
>
> On Sun, Nov 8, 2009 at 10:38 AM, Robert Ramey <ramey@...> wrote:
> > warnings=all
> > in the appropriate jamfile defaults?
>
> Shouldn't the default on each individual compiler be the default?

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
[phone], mobile [phone]
pbristow@...





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jeremiah Willcock]

On Sun, 8 Nov 2009, John Maddock wrote:

> 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!

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Robert Ramey wrote:
>
> 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.

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@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey]

Stewart, Robert wrote:

> Robert Ramey wrote:
>>
>> 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.
>
> 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?

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








_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Michael Fawcett]

On Mon, Nov 9, 2009 at 3:39 PM, Robert Ramey <ramey@...> wrote:
> Stewart, Robert 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?
>
> Of course I can conditionaly include pragma for this compiler.

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...

> 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.

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

>> 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?
>
> 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.

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.

> 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.

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[John Maddock]

> 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.

Hmm, I can run graph and property_map locally, but I don't have MPI
configured/installed - I suspect it would be a lot easier for some with that
already available to run those!

The logs are quite large, so I'll mail them separately.

John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Emil Dotchevski-3]

On Tue, Nov 10, 2009 at 1:58 AM, John Maddock <john@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gpderetta]

On Tue, Nov 10, 2009 at 7:33 PM, Emil Dotchevski
<emildotchevski@...> wrote:
> On Tue, Nov 10, 2009 at 1:58 AM, John Maddock <john@...> 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. :)
>

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

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@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost