Quantcast

[format] warning...warning...warning

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[format] warning...warning...warning

Boost - Users mailing list

Hello,

I’m a complete Boost newbie. I’ve been told very often that boost is the way to go for serious C++ coding, and I was not surprised to see such emphasis on the home page:

We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization”

 

So when I used the format library on my existing (non-trivial) project and first compiled… I was very very surprised to get my neat compilation console flooded with hundreds of warnings !

 

I acknowledge I activate many many warnings:

CXXFLAGS+=-Wall -Wextra -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization \

          -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs \

          -Wnoexcept -Woverloaded-virtual -Wredundant-decls -Wshadow \

          -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 \

          -Wswitch-default -Wundef -Wunused

 

The warnings were as trivial as (for example):

../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22: warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined [-Wundef]

#if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)

 

../ext/boost/boost/format/parsing.hpp:435:67: warning: conversion to ‘std::vector<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> >, std::allocator<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> > > >::size_type {aka unsigned int}’ from ‘int’ may change the sign of the result [-Wsign-conversion]

             string_type & piece = (cur_item==0) ? prefix_ : items_[cur_item-1].appendix_;

 

I understand they are only warning and the code is functionally correct and standard-wise correct.

Personally when I face such false warnings in my code, I change the code to remove the warning so that if a warning does make sense, I can notice it.

 

I thought a reference implementation would be written with such policy.

There’s no way I’m gonna read each of the hundreds of messages to understand if it is a mistake in my source code or a “shortcut” in boost library.

 

So this is my first user experience. Not impressed at all. Boost will not be my reference.

 


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
I thought a reference implementation would be written with such policy.

> There’s no way I’m gonna read each of the hundreds of messages to understand if it is a mistake in my source code or a “shortcut” in boost library.

 

> So this is my first user experience. Not impressed at all. Boost will not be my reference.


Boost is a community-maintained library. The contributors work tirelessly - for free - to make it the best, most comprehensive and correct library it can be.


You can help by filing bug reports when you find unsatisfactory behaviour.


You can also help by contributing bugfixes and updates.




On 23 March 2017 at 09:45, Arnaud RICHARD via Boost-users <[hidden email]> wrote:

Hello,

I’m a complete Boost newbie. I’ve been told very often that boost is the way to go for serious C++ coding, and I was not surprised to see such emphasis on the home page:

We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization”

 

So when I used the format library on my existing (non-trivial) project and first compiled… I was very very surprised to get my neat compilation console flooded with hundreds of warnings !

 

I acknowledge I activate many many warnings:

CXXFLAGS+=-Wall -Wextra -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization \

          -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs \

          -Wnoexcept -Woverloaded-virtual -Wredundant-decls -Wshadow \

          -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 \

          -Wswitch-default -Wundef -Wunused

 

The warnings were as trivial as (for example):

../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22: warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined [-Wundef]

#if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)

 

../ext/boost/boost/format/parsing.hpp:435:67: warning: conversion to ‘std::vector<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> >, std::allocator<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> > > >::size_type {aka unsigned int}’ from ‘int’ may change the sign of the result [-Wsign-conversion]

             string_type & piece = (cur_item==0) ? prefix_ : items_[cur_item-1].appendix_;

 

I understand they are only warning and the code is functionally correct and standard-wise correct.

Personally when I face such false warnings in my code, I change the code to remove the warning so that if a warning does make sense, I can notice it.

 

I thought a reference implementation would be written with such policy.

There’s no way I’m gonna read each of the hundreds of messages to understand if it is a mistake in my source code or a “shortcut” in boost library.

 

So this is my first user experience. Not impressed at all. Boost will not be my reference.

 


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
In reply to this post by Boost - Users mailing list

So this is my first user experience. Not impressed at all. Boost will not be my reference.


You can't just judge such a huge collection of C++ libraries by simply testing it on one example, with only one library.

Boost is a collection of libraries, not a single library. Hundreds of people contributed to it for many years and Boost has been recognized as one of the best set of C++ libraries by .... huh... the rest of the world.

Did you know, for example, it's a requirement for almost all C++ job in the world now, to know about Boost ?

So you have two solutions:

- the first one, which is the worst, is to stop using C++ because big parts of C++ (starting from C++11) come from Boost. In that case, you should simply learn another language,

- the second option, which I hope you will choose, is to work a bit harder learning C++ and Boost, asking to the community whenever you have a problem, even if you think it's trivial because we are always happy to help new users. And, when you're ready, contribute to Boost if you wish, to help us improve every single part of it.

Also you can have a look at this online book on Boost: https://theboostcpplibraries.com/


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
AMDG

On 03/23/2017 02:45 AM, Arnaud RICHARD via Boost-users wrote:

> Hello,
> I'm a complete Boost newbie. I've been told very often that boost is the way to go for serious C++ coding, and I was not surprised to see such emphasis on the home page:
> "We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization"
>
> So when I used the format library on my existing (non-trivial) project and first compiled... I was very very surprised to get my neat compilation console flooded with hundreds of warnings !
>
> I acknowledge I activate many many warnings:
> CXXFLAGS+=-Wall -Wextra -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization \
>           -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs \
>           -Wnoexcept -Woverloaded-virtual -Wredundant-decls -Wshadow \
>           -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 \
>           -Wswitch-default -Wundef -Wunused
>
> The warnings were as trivial as (for example):
> ../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22: warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined [-Wundef]
> #if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)
>

  If you compile with higher-than-default warning settings,
it's simplest to include Boost with -isystem instead of -I.
- At high warning settings, most additional warnings are spurious.
  Fixing them is a lot of effort for little gain.
- Every compiler warns about different issues.  Just because
  the code compiles without warnings on one compiler doesn't
  mean that other compilers will be equally happy.  There have
  even been cases in the past where compiler A warned if
  you did X, while compiler B warned if you /didn't/ do X.
- Sometimes "fixing" spurious warnings can create new bugs.

With that being said, I personally try to explicitly suppress
(with #pragma's) any known warnings that I don't care about.

> ../ext/boost/boost/format/parsing.hpp:435:67: warning: conversion to 'std::vector<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> >, std::allocator<boost::io::detail::format_item<char, std::char_traits<char>, std::allocator<char> > > >::size_type {aka unsigned int}' from 'int' may change the sign of the result [-Wsign-conversion]
>              string_type & piece = (cur_item==0) ? prefix_ : items_[cur_item-1].appendix_;
>
> I understand they are only warning and the code is functionally correct and standard-wise correct.
> Personally when I face such false warnings in my code, I change the code to remove the warning so that if a warning does make sense, I can notice it.
>
> I thought a reference implementation would be written with such policy.

You really shouldn't expect even those who are pedantic about
warnings to enable more than -Wall -Wextra.

> There's no way I'm gonna read each of the hundreds of messages to understand if it is a mistake in my source code or a "shortcut" in boost library.
>
> So this is my first user experience. Not impressed at all. Boost will not be my reference.
>

In Christ,
Steven Watanabe

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
On 2017-03-23 16:43, Steven Watanabe via Boost-users wrote:

> AMDG
>
> On 03/23/2017 02:45 AM, Arnaud RICHARD via Boost-users wrote:
>> Hello,
>> I'm a complete Boost newbie. I've been told very often that boost is
>> the way to go for serious C++ coding, and I was not surprised to see
>> such emphasis on the home page:
>> "We aim to establish "existing practice" and provide reference
>> implementations so that Boost libraries are suitable for eventual
>> standardization"
>>
>> So when I used the format library on my existing (non-trivial) project
>> and first compiled... I was very very surprised to get my neat
>> compilation console flooded with hundreds of warnings !
>>
>> I acknowledge I activate many many warnings:
>> CXXFLAGS+=-Wall -Wextra -Wcast-qual -Wctor-dtor-privacy
>> -Wdisabled-optimization \
>>           -Wformat=2 -Winit-self -Wlogical-op -Wmissing-include-dirs \
>>           -Wnoexcept -Woverloaded-virtual -Wredundant-decls -Wshadow \
>>           -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel
>> -Wstrict-overflow=5 \
>>           -Wswitch-default -Wundef -Wunused
>>
>> The warnings were as trivial as (for example):
>> ../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22:
>> warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined [-Wundef]
>> #if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)
>>
>
>   If you compile with higher-than-default warning settings,
> it's simplest to include Boost with -isystem instead of -I.
> - At high warning settings, most additional warnings are spurious.
>   Fixing them is a lot of effort for little gain.
> - Every compiler warns about different issues.  Just because
>   the code compiles without warnings on one compiler doesn't
>   mean that other compilers will be equally happy.  There have
>   even been cases in the past where compiler A warned if
>   you did X, while compiler B warned if you /didn't/ do X.
> - Sometimes "fixing" spurious warnings can create new bugs.
>
> With that being said, I personally try to explicitly suppress
> (with #pragma's) any known warnings that I don't care about.

Hi,

in this specific case the warning is not a false positive, or useless,
at elast as far as i udnerstand it. BOOST_GCC_VERSION_WORKAROUND_GUARD
is really not defined anywhere in boost, so this #ifdef block will never
be used.

>
>> ../ext/boost/boost/format/parsing.hpp:435:67: warning: conversion to
>> 'std::vector<boost::io::detail::format_item<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::allocator<boost::io::detail::format_item<char,
>> std::char_traits<char>, std::allocator<char> > > >::size_type {aka
>> unsigned int}' from 'int' may change the sign of the result
>> [-Wsign-conversion]
>>              string_type & piece = (cur_item==0) ? prefix_ :
>> items_[cur_item-1].appendix_;
>>
>> I understand they are only warning and the code is functionally
>> correct and standard-wise correct.
>> Personally when I face such false warnings in my code, I change the
>> code to remove the warning so that if a warning does make sense, I can
>> notice it.
>>
>> I thought a reference implementation would be written with such
>> policy.
>
> You really shouldn't expect even those who are pedantic about
> warnings to enable more than -Wall -Wextra.
>
>> There's no way I'm gonna read each of the hundreds of messages to
>> understand if it is a mistake in my source code or a "shortcut" in
>> boost library.
>>
>> So this is my first user experience. Not impressed at all. Boost will
>> not be my reference.
>>
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
AMDG

On 03/23/2017 01:51 PM, Oswin Krause wrote:

> On 2017-03-23 16:43, Steven Watanabe via Boost-users wrote:
>>
>>> The warnings were as trivial as (for example):
>>> ../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22:
>>> warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined [-Wundef]
>>> #if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)
>>>
>>
>> <snip>
>
> in this specific case the warning is not a false positive, or useless,
> at elast as far as i udnerstand it. BOOST_GCC_VERSION_WORKAROUND_GUARD
> is really not defined anywhere in boost, so this #ifdef block will never
> be used.

  No, that's wrong.  BOOST_WORKAROUND is intentionally
written so that an undefined XXX_WORKAROUND_GUARD
functions correctly.  In fact, the sole purpose of
BOOST_GCC_VERSION_WORKAROUND_GUARD is to suppress the
warning about BOOST_GCC_VERSION not being defined
(However, keeping a single global list of macros isn't
scalable, and it appears that the list isn't up-to-date).

In Christ,
Steven Watanabe

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
On 2017-03-23 22:35, Steven Watanabe via Boost-users wrote:

> AMDG
>
> On 03/23/2017 01:51 PM, Oswin Krause wrote:
>> On 2017-03-23 16:43, Steven Watanabe via Boost-users wrote:
>>>
>>>> The warnings were as trivial as (for example):
>>>> ../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22:
>>>> warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined
>>>> [-Wundef]
>>>> #if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)
>>>>
>>>
>>> <snip>
>>
>> in this specific case the warning is not a false positive, or useless,
>> at elast as far as i udnerstand it. BOOST_GCC_VERSION_WORKAROUND_GUARD
>> is really not defined anywhere in boost, so this #ifdef block will
>> never
>> be used.
>
>   No, that's wrong.  BOOST_WORKAROUND is intentionally
> written so that an undefined XXX_WORKAROUND_GUARD
> functions correctly.  In fact, the sole purpose of
> BOOST_GCC_VERSION_WORKAROUND_GUARD is to suppress the
> warning about BOOST_GCC_VERSION not being defined
> (However, keeping a single global list of macros isn't
> scalable, and it appears that the list isn't up-to-date).

Hi,

the code in question has a special workaround for gcc that is only
supposed to be active for certain old GCCs (i think older than 4.0.7).
The macro is never defined, therefore the code is never active,
therefore it is likely broken on that compiler. Alternatively, this code
block is never active and therefore it is dead code. Again, the warning
hinted towards a problem of code quality degradation.
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 2017-03-23 22:35, Steven Watanabe via Boost-users wrote:

> AMDG
>
> On 03/23/2017 01:51 PM, Oswin Krause wrote:
>> On 2017-03-23 16:43, Steven Watanabe via Boost-users wrote:
>>>
>>>> The warnings were as trivial as (for example):
>>>> ../ext/boost/boost/type_traits/is_default_constructible.hpp:16:22:
>>>> warning: "BOOST_GCC_VERSION_WORKAROUND_GUARD" is not defined
>>>> [-Wundef]
>>>> #if BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40700)
>>>>
>>>
>>> <snip>
>>
>> in this specific case the warning is not a false positive, or useless,
>> at elast as far as i udnerstand it. BOOST_GCC_VERSION_WORKAROUND_GUARD
>> is really not defined anywhere in boost, so this #ifdef block will
>> never
>> be used.
>
>   No, that's wrong.  BOOST_WORKAROUND is intentionally
> written so that an undefined XXX_WORKAROUND_GUARD
> functions correctly.  In fact, the sole purpose of
> BOOST_GCC_VERSION_WORKAROUND_GUARD is to suppress the
> warning about BOOST_GCC_VERSION not being defined
> (However, keeping a single global list of macros isn't
> scalable, and it appears that the list isn't up-to-date).

Forget my previous post. I now understood after reading the macro three
times again (i wrongly thought the guard would be one if the compiler
was active). Sorry for the noise.
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [format] warning...warning...warning

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 23.03.2017 09:45, Arnaud RICHARD via Boost-users wrote:

 

I understand they are only warning and the code is functionally correct and standard-wise correct.

Personally when I face such false warnings in my code, I change the code to remove the warning so that if a warning does make sense, I can notice it.

I used to do the same but fund such practice dangerous. It often resulted in poorer, less "natural" code, sometimes, albeit less frequently, degraded performance (not necessarily on platform reporting warning but another), or would even introduce bugs, if major change was required. Not to mention the cost of looking for balance between different warnings on different platforms and that of regression testing. In short, more pain than gain.

These days I prefer to selectively disable warnings I don't agree with (via command line options if possible, or #pragmas or similar) ... and very selectively enable warnings beyond some sensible level (defaults + select few are usually okay).

 

I thought a reference implementation would be written with such policy.

There’s no way I’m gonna read each of the hundreds of messages to understand if it is a mistake in my source code or a “shortcut” in boost library.

In a multi-platform, multi-compiler version library this is often difficult if not impossible to achieve. Not only one compiler might warn you're not doing X and the other that you are doing it, even different versions of the same compiler might disagree on whether X should be done or not. Heck, even the same version might if you compile against different language standards and/or dialects. I would find imposing any such or similar policy counter-productive and unjustified.

 

So this is my first user experience. Not impressed at all. Boost will not be my reference.

I, on the contrary, was impressed and still am after all these years. As others mentioned, not only C++11 received an enormous contribution from Boost, it is one of the few truly peer-reviewed general purpose libraries with a huge deployment base that gives you some assurance that many people have already found many defects that were already fixed and you are unlikely to stumble upon one.

Cheers,
Leon


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Loading...