On Fri, Aug 27, 2010 at 9:38 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:

vicente.botet wrote:

...

Last year there where two long threads about Boost Warning policy. If I'm not wrong nothing was concluded. I think that we can have two warning policies: one respect to the Boost users and one internal for Boost developement.

[snip]

The problem I foresee is that many warnings won't be triggered or useful until templates are instantiated by users with specific types.

I haven't done any tests but I'm assuming that #pragma GCC system_header is smart wrt this issue (for some definition of smart) because this pragma is used in their STL implementation headers, with the same desired effect and the same concerns. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On 8/27/2010 11:26 AM, Dave Abrahams wrote:

On Fri, Aug 27, 2010 at 8:26 AM, vicente.botet<vicente.botet@wanadoo.fr> wrote:

...

Hi all,

Last year there where two long threads about Boost Warning policy. If I'm not wrong nothing was concluded. I think that we can have two warning policies: one respect to the Boost users and one internal for Boost developement.

We can consider that Boost headers can be used by the users as system headers, so no warning is reported for these files. The main advantage I see is that it allows the users to don't mix the warnings comming from Boost and their own warnings.

Next follows a way to disable completly warnings for 3 compilers: Any Boost header file could be surrounded by

#if defined __GNUC__ #pragma GCC system_header #elif defined __SUNPRO_CC #pragma disable_warn #elif defined _MSC_VER #pragma warning(push, 1) #endif

and

#if defined __SUNPRO_CC #pragma enable_warn #elif defined _MSC_VER #pragma warning(pop) #endif

If we want to do something like that, it should be encapsulated in #include files:

#include<boost/detail/header_prefix.hpp>

...

#include<boost/detail/header_suffix.hpp>

I have never used the "GCC system_header" pragma, and have only gleaned its purpose from this list. Based only on that, it doesn't sound like you can stick it in an encapsulation header as above. But other than that, yes, putting the MSVC and sun pragmas in prefix/suffix files would be good. - Jeff

On 28 August 2010 10:26, John Maddock <boost.regex@virgin.net> wrote:

...

Last year there where two long threads about Boost Warning policy. If I'm not wrong nothing was concluded. I think that we can have two warning policies: one respect to the Boost users and one internal for Boost developement.

There was some progress towards fixing warnings:

https://svn.boost.org/trac/boost/wiki/WarningFixes

Also I'm fairly sure that Paul Bristow started a "How to fix warnings" guidelines page, but I can't find it right now :-(

Oh, sorry about that. I removed the links when I moved the guidelines back to the main website and forgot to provide a way to find the wiki guidelines. https://svn.boost.org/trac/boost/wiki/Guidelines Daniel

----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Saturday, August 28, 2010 11:26 AM Subject: Re: [boost] Towards a Warning free code policy proposal

...

Last year there where two long threads about Boost Warning policy. If I'm not wrong nothing was concluded. I think that we can have two warning policies: one respect to the Boost users and one internal for Boost developement.

There was some progress towards fixing warnings:

https://svn.boost.org/trac/boost/wiki/WarningFixes

Also I'm fairly sure that Paul Bristow started a "How to fix warnings" guidelines page, but I can't find it right now :-(

I can see it now that the wiki has been recovered.

...

We can consider that Boost headers can be used by the users as system headers, so no warning is reported for these files. The main advantage I see is that it allows the users to don't mix the warnings comming from Boost and their own warnings.

...

Next follows a way to disable completly warnings for 3 compilers: Any Boost header file could be surrounded by

I'm completely against disabling warnings in such a blanket manner for a number of reasons:

1) It doesn't fix anything, it hides it.

I would say, it enables users to hide Boost warnings. If you prefer instead on setting the defaul as warnings disabled, we can enable them as default, and let the user disable them with just one define.

2) I have found legitimate bugs in both my code and others as a result of fixing what looked to be "busy-body" warnings at first glance. As I said in the initial post: "Of course this policy don't mean that the developer should not take care of the warnings. " 3) As others have noted, some warnings are only emitted when a template is instantiated with certain template arguments - in this case the warning may be telling the user something important about the template arguments that they're using and *should be seen*.

The user can always define BOOST_ENABLE_WARNINGS, so warnings will be no suppresed using this technique.

4) Blanket disabling does nothing for compilers that don't have such mechanisms -

Well there are 3 main compiler family that allow it. I don't know for others.

indeed I would contend that it would make things worse, as the trend would be towards "don't worry about warnings".

I don't agree. If regressions are runned with BOOST_ENABLE_WARNINGS and if as other sugested we have some compilers with warning-as-error set, this could be the bases of a clear warning free strategy.

5) I worry that this would lead towards poorer quality code and an "out of sight out of mind" mentality.

I repeat. I'm not purposing to don't fix the warnings. Just to give the user the posibility to supress all the Boost warnings.

6) As a last resort, we can always resort to - preferably selective - disabling methods when all else fails.

I agree, we need to eliminate the warnings and suppress them when all else fails in the most localized way. The problem is that currently there are a lot of warnings that are not hadled. The strategy I'm porposing just helps to achieve 0 warnings (for some compilers :) for users that needs this warning free code as a preamble to install Boost on his project.

So... yes we need to do something about warnings, and yes I would like to see our tests run with "warnings as errors" for some compilers at least, but please not like this!

Could some of the testers set up a configuration with warnings as errors set? Best, Vicente

I've casually followed this discussion and I'm sort of left confused. My experience with trying to get to zero warnings is pretty simple. I looked at each warning. a) some were potential bugs and it was easy to fix - I fixed them. b) some were potential bugs and harder to fix - I fixed them. c) some were "cosmetic" bugs - e.g. declaration hide a base class variable - I fixed most of them. But in some cases that was my explicit intention d) some were too hard to fix/eliminate comparison between signed/unsigned - I just left them because I didn't know how to fix them e) some were "cosmetic" warning which varied a lot between compilers. This started to turn into a game of "whack-a-mole" in that that seemed to be never ending and would require a lot of compiler specific code - I left them. f) some were in the library build - I considered these lower priority as they would only occur at install time. g) some were in tests - I considered these slightly higher priority but still left some. My reasoning is that it seems that users never run the test suite for libraries they use. (another topic) h) the rest would show in users code - I considered highest priority since this is were most users would see the warnings. In addition, I use BOOST_SERIALIZATION_STATIC_WARNING in lots of places to flag code which is unlikely to produce what the user intended. for example, exporting a derived class which is not virtual will not result in serializing a derived class through a base class pointer. I'm not proposing anything. I'm just saying that trying to get a "policy" on warnings seems likely to fail in my opinion. Requiring 0 warnings is not realistic. The only thing I can suggest is a) expect a reasonable effort to minimize warnings b) specific places where they can't be eliminated on all platforms should have a comment in the source code at the right spot. c) perhaps a short statement on some warnings which can't be surpressed in the libraries release notes or documentation Robert Ramey

On Sat, Aug 28, 2010 at 2:11 PM, Mika Heiskanen <mika.heiskanen@fmi.fi> wrote:

On Sat, 2010-08-28 at 22:17 +0300, Robert Ramey wrote:

...

d) some were too hard to fix/eliminate comparison between signed/unsigned - I just left them because I didn't know how to fix them

Am I missing some complication I'm not aware of?

In my experience this warning is just about always the result of using int for variables which should be of type size_t, as in

 for(int i=0; i<object.size(); i++)

If I cannot redefine all the types to unsigned, something like this usually fixes the problem:

 if ( size >= 0 && static_cast<size_t>(size) < object.size() )

Writing static_casts is annoying, but it is often necessary if you want to remain -Wall -pedantic.

This is a good illustration of one of the problems with "fixing" warnings: this is often done with casts, and casts are way more dangerous than the built-in implicit conversions for which the compiler is warning about. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On 29 August 2010 01:23, Emil Dotchevski <emil@revergestudios.com> wrote:

...

Writing static_casts is annoying, but it is often necessary if you want to remain -Wall -pedantic.

This is a good illustration of one of the problems with "fixing" warnings: this is often done with casts, and casts are way more dangerous than the built-in implicit conversions for which the compiler is warning about.

Is it really worse? Here are the situations we are comparing: 1. Silencing the warnings so that users and library developers can't look at them. 2. Generating hundreds to thousands of warnings so that users and library developers don't look at them. The only way to effectively use warnings to look for problems is to have a zero warning policy. --  Nevin Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

On 28/08/2010 22:11, Mika Heiskanen wrote:

On Sat, 2010-08-28 at 22:17 +0300, Robert Ramey wrote:

...

d) some were too hard to fix/eliminate comparison between signed/unsigned - I just left them because I didn't know how to fix them

Comparing signed and unsigned integers can be a serious issue, since that means you might not deal with negative cases properly, which is why there are warnings.

Am I missing some complication I'm not aware of?

In my experience this warning is just about always the result of using int for variables which should be of type size_t, as in

for(int i=0; i<object.size(); i++)

I never understood why some people even write code like this. There are several problems with this: - using int, even though int has no direct relation with the size type of 'object' - using indexes and size instead of iterators, which have an idiomatic way to be traversed - making the code rely on a particular data structure, instead of allowing it to work with any sequence type, allowing the code to be more easily changed.

If I cannot redefine all the types to unsigned, something like this usually fixes the problem:

if ( size>= 0&& static_cast<size_t>(size)< object.size() )

size_t(size) instead of static_cast<size_t>(size) should work just fine. No need for any cast.

On Sun, Aug 29, 2010 at 2:50 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:

I never understood why some people even write code like this. There are several problems with this:  - using int, even though int has no direct relation with the size type of 'object'  - using indexes and size instead of iterators, which have an idiomatic way to be traversed  - making the code rely on a particular data structure, instead of allowing it to work with any sequence type, allowing the code to be more easily changed.

This is besides the point.

...

If I cannot redefine all the types to unsigned, something like this usually fixes the problem:

  if ( size>= 0&&  static_cast<size_t>(size)<  object.size() )

size_t(size) instead of static_cast<size_t>(size) should work just fine. No need for any cast.

T(x) is even more dangerous than static_cast because in certain situations it is equivalent to a C-style cast. The safest thing to do is to let the carefully designed implicit conversion system of the language take care of things. At most, I'd add assert(size>=0) but that's often an overkill. The best way to avoid this warning in this case is to compare with != instead of <. I like != better anyway because it is less defensive, it breaks easier if I mess up the loop. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On 30.08.2010 19:26, Nevin Liber wrote:

On 29 August 2010 04:50, Mathias Gaunard<mathias.gaunard@ens-lyon.org> wrote:

...

for(int i=0; i<object.size(); i++)

I never understood why some people even write code like this. There are several problems with this: - using int, even though int has no direct relation with the size type of 'object'

Until C++0x and auto, it can be fairly painful to get size_type of the container, since you can't get it from the "object" variable itself. Personally, I go through the pain, but I can certainly understand why others may not. Library code, such as Boost, should do this for correctness.

In such cases I simply use std::size_t. In 99.999% of cases it is the size_type of the container and it's short enough.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Raymond Wan Sent: Sunday, August 29, 2010 6:53 AM To: boost@lists.boost.org Subject: Re: [boost] Towards a Warning free code policy proposal <snip>

As a user who is somewhat following the discussion, I have to say that the approach used by gcc in terms of handling warnings is good. Warnings are shown and you have to add flags such as -Wall to disable them. That at least forces users to do something because of the warnings -- either act on it by looking at their code or realizing that the warning is unimportant and to find the flag that would remove it. Perhaps a more viable solution is to produce warnings and errors that could be searched in a part of the Boost documentation (i.e., dedicated to dealing with warnings) that says what caused the warning and how to disable it if the user is satisfied that it is not important.

I can see why this issue would be brought up -- boost warnings are intimidating to users. But (IMHO), removing warnings will make users not knowledgeable in Boost (such as myself) to becoming more sloppy. Instead of that, maybe keeping the warnings but having documentation specifically explaining how they can be suppressed might be a bit better

https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines tells you quite a lot about warnings, including gcc and MSVC (It's a bit thin on other compilers - more info please). than

having them off by default for users.

I'd like to see Boost getting rid of warnings that come from its code, so that all warnings are relevant to the user. The above, and references therein, (written for Boost developers) may still be useful to users. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

Hello All, How to deal with warning? - If code produces warning disable it? You will end with numerous ifdefs for each compiler: GCC, Intel, MSVC, SunStudio and much more. You would even find yourself subdividing each of the following cases for compiler versions where each one of them produce some kind of warning and finally you will disable some important warning accidentally. - If the code is produces warning, fix it. And you end with 100 stupid cases where each compiler thinks it is important, * gcc warns on polymorphic class without virtual destructor even if sometimes you don't need it. * MSVC calls every single standard C library function dangerous like fopen, localtime and so-on. * Intel produces multiple lines of usless remarks on temporary objects. - What warning level to use under GCC -Wall? -Wextra? -Wpedantic? and under MSVC /w2? /w3? or /w4? I have never seen a big project that compiles cleanly with /w4 under MSVC. IMHO: let library developer decide what to disable and what policy he should use. Developer that respects himself would code the way the code compiles with severe warning level. My $0.02 Artyom

Artyom wrote:

IMHO: let library developer decide what to disable and what policy he should use. Developer that respects himself would code the way the code compiles with severe warning level.

Boost is thought of as a whole made of parts. If the parts differ wildly in how things are addressed, the whole suffers. That's why we have high documentation standards for all Boost libraries, for example. Consequently, without some minimum standard for warnings, there may be too much variation. There should be guidelines on things to avoid when trying to fix warnings. Emil's favorite is to avoid casts because they bypass the implicit type conversion system in the language and can hide problems. I don't agree entirely with his concerns, but there is value in what he says. We need guidelines that prescribe and others that proscribe to ensure best practice. _____ 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.

Andrey Semashev wrote:

I honestly don't understand those who think that warning-free code is somehow more solid than the code which emits warnings.

The intended goal is to allow Boost users to focus on warnings from their own code, at whatever warnings level they like. The more warnings Boost code triggers, the more such users will grow to ignore all warnings which means compilers cannot assist them in writing safer code. The suggestion to be able to suppress all warnings from Boost headers does that, with some possibility of suppressing some triggered by user interaction with Boost code that shouldn't be ignored. _____ 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.

Andrey Semashev wrote:

As I said, users can already disable all warnings from third party headers.

I know one can use -isystem with GCC, but how is that done with other compilers? _____ 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.

Andrey Semashev wrote:

On 30.08.2010 21:24, Stewart, Robert wrote:

...

Andrey Semashev wrote:

...

As I said, users can already disable all warnings from third party headers.

I know one can use -isystem with GCC, but how is that done with other compilers?

With MSVC (and, probably ICL) you can use pragmas around Boost headers.

I thought you were implying a simple, -isystem-like approach whereby just using a command line option would silence the warnings.

I don't know about other compilers, but if there are similar tricks for them, they can be applied on user's side just as well as on Boost's side.

That means every user that wants that behavior must create a set of local headers to include before Boost headers in order to get the surrounding pragmas or whatever. That's not very polite, but I suppose if the assumption is that few have that problem/concern, then they ought to pay for the trouble rather than force the Boost maintainers to do so. Unfortunately, Boost libraries vary from release to release, so maintaining a parallel set of headers is rather cumbersome for library users. _____ 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 Mon, Aug 30, 2010 at 10:55 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:

My point is that the warning-free requirement (at high levels) seems quite specific and, to my mind, quite pointless. Additionally, suppressing all warnings in all Boost headers is (a) compiler-specific, (b) tedious and (c) may not be what the user actually wants. Therefore let the users decide what and how to do about warnings.

Here's my suggestion: * We make no requirement on developers that they address warnings * We choose a warning level we're going to test at for each compiler * On our testing pages we publish the number of warnings for each test along with the number of errors * On our guidelines page we publish a list of safe ways to "avoid" various warnings (e.g. use implicit conversions) and perhaps less-safe ways to "suppress" them (e.g. use a cast). -- Dave Abrahams BoostPro Computing http://www.boostpro.com

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dave Abrahams Sent: Tuesday, August 31, 2010 5:46 AM To: boost@lists.boost.org Subject: Re: [boost] Towards a Warning free code policy proposal

On Mon, Aug 30, 2010 at 10:55 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:

...

My point is that the warning-free requirement (at high levels) seems quite specific and, to my mind, quite pointless. Additionally, suppressing all warnings in all Boost headers is (a) compiler-specific, (b) tedious and (c) may not be what the user actually wants. Therefore let the users decide what and how to do about warnings.

I think this is really, really unhelpful. And I think there is enough opinions and evidence that getting rid of warnings makes the code better. So many, perhaps most, people (if not all) believe getting 'warnings free' remains a good objective.

Here's my suggestion:

* We make no requirement on developers that they address warnings We do this now.

* We choose a warning level we're going to test at for each compiler We do this now - but I'd like to see it at W all.

* On our testing pages we publish the number of warnings for each test along with the number of errors We (someone) could do this, but it might be some work to get a warnings count on all systems? (We might more easily be able to get a count != 0).

(But I note that many warnings arise from libraries when they are used by other libraries, for example Boost.Format and Fusion used by Boost.Math. This makes warnings count much less useful) .

* On our guidelines page we publish a list of safe ways to "avoid". various warnings (e.g. use implicit conversions) and perhaps less-safe ways to "suppress" them (e.g. use a cast).

We already have quite a lot on this at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines (but more expert input/correction/improvement is very welcome. You can edit it, or I will handle the editorial bit if that is easier). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

On Tue, Aug 31, 2010 at 7:00 AM, David Abrahams <dave@boostpro.com> wrote:

...

We already have quite a lot on this at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines (but more expert input/correction/improvement is very welcome.  You can edit it, or I will handle the editorial bit if that is easier).

Wow, I didn't even know about this page.  Nice work, Paul!  OK, then, IMO the status quo is mostly fine except that we have no metrics to help developers know how they're doing on warning suppression.

We sort of do, if users don't complain about warnings, all is good. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

We already have quite a lot on this at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines (but more expert input/correction/improvement is very welcome. You can edit it, or I will handle the editorial bit if that is easier).

Not "expert" input, but the table under Specific Warnings and Suggested Actions :: Microsoft is barely readable for me (Firefox 3.6.8). Can't the columns in row i have the same width as the columns in row j for all i,j? On the issue of a casting between signed and unsigned types (error 4244 in VC), I am a bit concerned I am missing something. Why is there significant discussion about choosing which cast to make the warning go away? I am labouring under the impression that boost::numeric_cast was invented to do those conversions? Pete

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Bartlett Sent: Tuesday, August 31, 2010 3:06 PM To: boost@lists.boost.org Subject: Re: [boost] Towards a Warning free code policy proposal

...

We already have quite a lot on this at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines (but more expert input/correction/improvement is very welcome. You can edit it, or I will handle the editorial bit if that is easier).

Not "expert" input, but the table under Specific Warnings and Suggested Actions :: Microsoft is barely readable for me (Firefox 3.6.8). Can't the columns in row i have the same width as the columns in row j for all i,j?

Well if the Trac wiki-style can, I'm a novice who has yet to discover it ;-) Any experts out there who know more than I do? But by enlarging and contracting you can at least read everything. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

On 2 September 2010 11:20, Daniel James <dnljms@gmail.com> wrote:

Personally, I wouldn't use a table for the data, it crams too much into a small space. I'd just use a separate page for each compiler.

Here's an example of what I mean. https://svn.boost.org/trac/boost/wiki/Guidelines/Warnings/Microsoft Note that the warnings are listed on the right for quick access (this is automatically done from the headers). If you like it, I'll copy and reformat the rest of the warnings. Although I'm not sure if a definition list is the best way to lay out the details. Daniel

On Sep 2, 2010, at 4:26 PM, Stephan T. Lavavej wrote:

[Daniel James]

...

Here's an example of what I mean. https://svn.boost.org/trac/boost/wiki/Guidelines/Warnings/Microsoft

This should mention that Boost headers should push/disable/pop. If they just disable, then they're disabling that warning for the rest of the translation unit.

Does that work for warnings that occur in template instantiations? Sebastian

On 3 September 2010 00:26, Stephan T. Lavavej <stl@exchange.microsoft.com> wrote:

[Daniel James]

...

Here's an example of what I mean. https://svn.boost.org/trac/boost/wiki/Guidelines/Warnings/Microsoft

This should mention that Boost headers should push/disable/pop. If they just disable, then they're disabling that warning for the rest of the translation unit.

I didn't include that because I was just making a suggestion about how the warnings could be formatted. The full document is still at: https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines Which describes pushing and popping warnings (I'm sure Paul would appreciate any help with this). If we decide to put compiler specific content on separate pages, then the detail will probably go on the individual compiler pages, with an overview on the main page. Daniel

On Thu, Sep 2, 2010 at 3:35 PM, Daniel James <dnljms@gmail.com> wrote:

On 2 September 2010 11:20, Daniel James <dnljms@gmail.com> wrote:

...

Personally, I wouldn't use a table for the data, it crams too much into a small space. I'd just use a separate page for each compiler.

Here's an example of what I mean.

https://svn.boost.org/trac/boost/wiki/Guidelines/Warnings/Microsoft

I think that this would be more helpful if it just listed how each warning responds to various edits instead of suggesting how it should be fixed. For example, the unreferenced formal parameter warning section could look like this: C4100 (Unreferenced formal parameter) - delete the parameter name or add a reference to the parameter in the function: (void)foo; Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On 03/09/10 05:23, Jeff Flinn wrote:

...

C4100 (Unreferenced formal parameter) - delete the parameter name or add a reference to the parameter in the function: (void)foo;

I thought I remember the latter triggering another warning. I don't remember the exact verbage or compiler. Or does the prefix (void) supress that?

could be fixed by having an helper details function like: void unused_param(T const&) {} and do unused_param(oo);

Andrey Semashev wrote:

On 08/30/2010 11:00 PM, Stewart, Robert wrote:

...

Andrey Semashev wrote:

...

I don't know about other compilers, but if there are similar tricks for them, they can be applied on user's side just as well as on Boost's side.

That means every user that wants that behavior must create a set of local headers to include before Boost headers in order to get the surrounding pragmas or whatever. That's not very polite, but I suppose if the assumption is that few have that problem/concern, then they ought to pay for the trouble rather than force the Boost maintainers to do so. Unfortunately, Boost libraries vary from release to release, so maintaining a parallel set of headers is rather cumbersome for library users.

Well, it doesn't _require_ the headers. The common practice in Windows development is to have StdAfx.h, which is used to generate pch. Most third party headers are included there, so users can simply wrap all Boost includes in the project with pragmas in StdAfx.h. That's what I sometimes do.

Supposing that's the direction followed, it would be appropriate to have information on the web site about best practices for suppressing all or most warnings from Boost headers in user environments. Thus, you could describe the PCH approach on such a page for the benefit of Windows developers and another could describe the approach needed for other compilers/platforms. That information should be prominently featured for easy discovery.

My point is that the warning-free requirement (at high levels) seems quite specific and, to my mind, quite pointless. Additionally, suppressing all warnings in all Boost headers is (a) compiler- specific, (b) tedious and (c) may not be what the user actually wants. Therefore let the users decide what and how to do about warnings.

There may well be no other way to reach agreement. _____ 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 30.08.2010 21:50, Bo Persson wrote:

This is from the library writer's perspective. What about the potential library user?

That was not limited to the library developer's perspective. I strive for this policy as a library user, too (and as a Boost user, in particular). Although to that end, as a user I also usually write portable code.

On 08/30/2010 11:14 PM, vicente.botet wrote:

----- Original Message ----- From: "Andrey Semashev"<andrey.semashev@gmail.com> To:<boost@lists.boost.org> Sent: Monday, August 30, 2010 6:51 PM Subject: Re: [boost] Towards a Warning free code policy proposal

...

On the original topic: * I don't think that adding the ability to mask out all Boost warnings is of much use. <snip> That's why I don't think that adding the policy is a good idea for Boost in general. However, particular library developers may offer this feature of their own libraries, on their free will.

Andrey,

If I can recall the original topic, what I proposed is something you already do in quite a lot of files in Boost.Expression.

Um... I'm not a maintainer of Boost.Exception. I believe, Emil is the library maintainer.