Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #88268 > unrolled thread

g++ -c -Werror -Weverything exercise_2_17.cpp

Back to article view | Back to comp.lang.c++

Contents

  g++  -c -Werror -Weverything exercise_2_17.cpp "gdo...@gmail.com" <gdotone@gmail.com> - 2022-12-27 01:22 -0800
    Re: g++ -c -Werror -Weverything exercise_2_17.cpp Öö Tiib <ootiib@hot.ee> - 2022-12-27 02:50 -0800
    Re: g++  -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:33 +0000
      Re: g++ -c -Werror -Weverything exercise_2_17.cpp Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-29 23:20 +0200
        Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2022-12-30 21:05 +0000
          Re: g++ -c -Werror -Weverything exercise_2_17.cpp Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-30 23:33 +0200
            Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2022-12-31 15:05 +0000
              Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2022-12-31 16:40 +0100
                Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 06:27 +0000
                  Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2023-01-03 08:51 +0100
                    Re: g++ -c -Werror -Weverything exercise_2_17.cpp Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 09:13 +0000
                      Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2023-01-03 11:47 +0100
              Re: g++ -c -Werror -Weverything exercise_2_17.cpp Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-31 18:50 +0200
                Re: g++ -c -Werror -Weverything exercise_2_17.cpp David Brown <david.brown@hesbynett.no> - 2022-12-31 18:47 +0100

#88268 — g++ -c -Werror -Weverything exercise_2_17.cpp

compiling a simple program, including <iostream>

using:
g++  -c -Werror -Weverything exercise_2_17.cpp

-Weverything is producing this:

g++ -c -Werror -Weverything exercise_2_17.cpp 
error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
1 error generated.

if I don't use -Weverything source compiles fine, no errors or warning messages. 

what does that mean?
using an intel based Mac, clang++ gives the same message.

Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

apparently g++ uses the clang++ compiler. 

g++ -v
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

adding -Wsystem-headers  gives so many warnings the it stops at its default limit.

[toc] | [next] | [standalone]

#88269 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

On Tuesday, 27 December 2022 at 11:22:15 UTC+2, gdo...@gmail.com wrote:
> compiling a simple program, including <iostream> 
> 
> using: 
> g++ -c -Werror -Weverything exercise_2_17.cpp 
> 
> -Weverything is producing this: 
> 
> g++ -c -Werror -Weverything exercise_2_17.cpp 
> error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories] 
> 1 error generated. 
> 
> if I don't use -Weverything source compiles fine, no errors or warning messages. 
> 
> what does that mean? 
> 
The -Weverything of clang produces all kinds of silly warnings some of what
you might want to disable. If you want to disable only that warning then
use -Wno-poison-system-directories


> using an intel based Mac, clang++ gives the same message. 
> 
> Apple clang version 14.0.0 (clang-1400.0.29.202) 
> Target: x86_64-apple-darwin22.1.0 
> Thread model: posix 
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 
> 
> apparently g++ uses the clang++ compiler. 
> 
> g++ -v 
> Apple clang version 14.0.0 (clang-1400.0.29.202) 
> Target: x86_64-apple-darwin22.1.0 
> Thread model: posix 
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 
> 
> adding -Wsystem-headers gives so many warnings the it stops at its default limit.

Yes, there are no gcc installed on Apple by default. You need to install
it yourself if you want real gcc and of course there are artificial difficulties
made by Apple to that. But without challenges ... life is boring. ;-)
 

[toc] | [prev] | [next] | [standalone]

#88299

gdo...@gmail.com <gdotone@gmail.com> wrote:
> compiling a simple program, including <iostream>
> 
> using:
> g++  -c -Werror -Weverything exercise_2_17.cpp
> 
> -Weverything is producing this:
> 
> g++ -c -Werror -Weverything exercise_2_17.cpp 
> error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
> 1 error generated.
> 
> if I don't use -Weverything source compiles fine, no errors or warning messages. 

Don't enable all warnings. Some warnings are extremely specific and not even
intended for regular use, only for very special circumstances.

-Wall is a relatively safe bet. If you want a bit more, also add -Wextra.

[toc] | [prev] | [next] | [standalone]

#88300 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

29.12.2022 22:33 Juha Nieminen kirjutas:
> gdo...@gmail.com <gdotone@gmail.com> wrote:
>> compiling a simple program, including <iostream>
>>
>> using:
>> g++  -c -Werror -Weverything exercise_2_17.cpp
>>
>> -Weverything is producing this:
>>
>> g++ -c -Werror -Weverything exercise_2_17.cpp
>> error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
>> 1 error generated.
>>
>> if I don't use -Weverything source compiles fine, no errors or warning messages.
> 
> Don't enable all warnings. Some warnings are extremely specific and not even
> intended for regular use, only for very special circumstances.
> 
> -Wall is a relatively safe bet. If you want a bit more, also add -Wextra.

There are other warnings in addition to -Wall -Wextra which I have found 
to be useful for me, e.g.

-Wpointer-arith -Wcast-align -Wstrict-aliasing=1 -Werror=type-limits

And vice versa, -Wall -Wextra triggers some unneeded warnings which I am 
switching off by -Wno-... options.

[toc] | [prev] | [next] | [standalone]

#88312 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> Don't enable all warnings. Some warnings are extremely specific and not even
>> intended for regular use, only for very special circumstances.
>> 
>> -Wall is a relatively safe bet. If you want a bit more, also add -Wextra.
> 
> There are other warnings in addition to -Wall -Wextra which I have found 
> to be useful for me, e.g.
> 
> -Wpointer-arith -Wcast-align -Wstrict-aliasing=1 -Werror=type-limits

There was also the warning (which exact name I don't remember right now)
that will warn for uses of C-style casts. Depending on how much of a
C++ purist one is, it might also be worth considering.

> And vice versa, -Wall -Wextra triggers some unneeded warnings which I am 
> switching off by -Wno-... options.

Can you give some examples?

[toc] | [prev] | [next] | [standalone]

#88313 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

30.12.2022 23:05 Juha Nieminen kirjutas:
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> Don't enable all warnings. Some warnings are extremely specific and not even
>>> intended for regular use, only for very special circumstances.
>>>
>>> -Wall is a relatively safe bet. If you want a bit more, also add -Wextra.
>>
>> There are other warnings in addition to -Wall -Wextra which I have found
>> to be useful for me, e.g.
>>
>> -Wpointer-arith -Wcast-align -Wstrict-aliasing=1 -Werror=type-limits
> 
> There was also the warning (which exact name I don't remember right now)
> that will warn for uses of C-style casts. Depending on how much of a
> C++ purist one is, it might also be worth considering.
> 
>> And vice versa, -Wall -Wextra triggers some unneeded warnings which I am
>> switching off by -Wno-... options.
> 
> Can you give some examples?

Sure, these are probably specific to our codebase:

-Wno-missing-field-initializers -Wno-unused-parameter 
-Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses

The first one is there probably because we have many classes whose 
members are often not initialized by the constructions, but later, by 
the framework.

[toc] | [prev] | [next] | [standalone]

#88316 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

Paavo Helde <eesnimi@osa.pri.ee> wrote:
> Sure, these are probably specific to our codebase:
> 
> -Wno-missing-field-initializers -Wno-unused-parameter 
> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
> 
> The first one is there probably because we have many classes whose 
> members are often not initialized by the constructions, but later, by 
> the framework.

I think that using [[maybe_unused]] is better than disabling the warning
because it more explicitly indicates that it being unused is not a mistake
and the programmer was aware of it.

One warning, or was it actually an error, that does annoy me quite a bit
is the "narrowing conversion" thingie. I think it was introduced in C++11
or newer, and was never a problem before. To this day I'm not sure why
that warning/error is necessary.

(Maybe it has something to do with uniform initialization, which turned
out to be quite a mess?)

[toc] | [prev] | [next] | [standalone]

#88319 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

On 31/12/2022 16:05, Juha Nieminen wrote:
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> Sure, these are probably specific to our codebase:
>>
>> -Wno-missing-field-initializers -Wno-unused-parameter
>> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
>>
>> The first one is there probably because we have many classes whose
>> members are often not initialized by the constructions, but later, by
>> the framework.
> 
> I think that using [[maybe_unused]] is better than disabling the warning
> because it more explicitly indicates that it being unused is not a mistake
> and the programmer was aware of it.
> 

It also has the advantage of allowing people to compile with other flags 
(such as -Wextra without the -Wno- flag) without triggering the warning.

> One warning, or was it actually an error, that does annoy me quite a bit
> is the "narrowing conversion" thingie. I think it was introduced in C++11
> or newer, and was never a problem before. To this day I'm not sure why
> that warning/error is necessary.
> 
> (Maybe it has something to do with uniform initialization, which turned
> out to be quite a mess?)

I think warnings (or errors) about narrowing conversions are a good 
idea.  If I accidentally try to use a double as an integer, I'd rather 
be told.

I find the "uniform initialisation" syntax ugly for scaler variables, 
but the fact that narrowing conversions are not allowed is an advantage 
here IMHO.

[toc] | [prev] | [next] | [standalone]

#88364 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

David Brown <david.brown@hesbynett.no> wrote:
>> One warning, or was it actually an error, that does annoy me quite a bit
>> is the "narrowing conversion" thingie. I think it was introduced in C++11
>> or newer, and was never a problem before. To this day I'm not sure why
>> that warning/error is necessary.
>> 
>> (Maybe it has something to do with uniform initialization, which turned
>> out to be quite a mess?)
> 
> I think warnings (or errors) about narrowing conversions are a good 
> idea.  If I accidentally try to use a double as an integer, I'd rather 
> be told.

The problem is that the "narrowing" warning/error is only issued when
eg. using a double within an initializer list that expects a float,
it doesn't happen in *any* other situation where a double is being
implicitly converted into a float.

I cannot comprehend the reason to make that one particular situation
special.

[toc] | [prev] | [next] | [standalone]

#88366 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

On 03/01/2023 07:27, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>> One warning, or was it actually an error, that does annoy me quite a bit
>>> is the "narrowing conversion" thingie. I think it was introduced in C++11
>>> or newer, and was never a problem before. To this day I'm not sure why
>>> that warning/error is necessary.
>>>
>>> (Maybe it has something to do with uniform initialization, which turned
>>> out to be quite a mess?)
>>
>> I think warnings (or errors) about narrowing conversions are a good
>> idea.  If I accidentally try to use a double as an integer, I'd rather
>> be told.
> 
> The problem is that the "narrowing" warning/error is only issued when
> eg. using a double within an initializer list that expects a float,
> it doesn't happen in *any* other situation where a double is being
> implicitly converted into a float.
> 
> I cannot comprehend the reason to make that one particular situation
> special.

It is better than nothing.

But I agree with you that narrowing conversions can definitely be wrong, 
or at least risky, in other circumstances too.  /Increasing/ the type 
size silently can also be an issue (imagine using a microcontroller with 
hardware single-precision floating point, but doubles in software - 
these are very common).

C++ inherited a range of automatic conversions and promotions from C. 
They are often convenient, but occasionally problematic.  They can't be 
removed from the language - backwards compatibility is too strong for 
that.  It would usually not make sense to have compiler warning options 
either, as the false positives would likely swamp the useful warnings.

As I see it, there are three options.  Switch to a stricter language, 
such as Ada.  Make your own types, such as "Float" and "Double", without 
automatic conversions.  Or campaign for a new feature in C++ where a 
declaration like "void foo(explicit float f)" would require a float 
argument without conversion.

[toc] | [prev] | [next] | [standalone]

#88367 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

David Brown <david.brown@hesbynett.no> wrote:
>> I cannot comprehend the reason to make that one particular situation
>> special.
> 
> It is better than nothing.

Now that I think about it, I actually don't know if the "narrowing
conversion" warning given by gcc (and I think also clang) when such
a conversion happens in initializer lists in particular is just
because the developers of the compiler decided so, or whether the
newer C++ standards mandate something along those lines.

However, looking it up, it seems that indeed the C++11 standard
forbids list-initialization with implicit narrowing conversions.
(It also seems to disallow it for aggregate initialization.)

It's a bit annoying to have this inconsistency in the language.
(Overall, as great as "uniform initialization" sounds on paper,
in practice it causes a lot of headaches. At a very minimum they
should have used a different syntax for initializer lists.)

[toc] | [prev] | [next] | [standalone]

#88371 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

On 03/01/2023 10:13, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>> I cannot comprehend the reason to make that one particular situation
>>> special.
>>
>> It is better than nothing.
> 
> Now that I think about it, I actually don't know if the "narrowing
> conversion" warning given by gcc (and I think also clang) when such
> a conversion happens in initializer lists in particular is just
> because the developers of the compiler decided so, or whether the
> newer C++ standards mandate something along those lines.

The standards mandate it (as you note below).

> 
> However, looking it up, it seems that indeed the C++11 standard
> forbids list-initialization with implicit narrowing conversions.
> (It also seems to disallow it for aggregate initialization.)
> 
> It's a bit annoying to have this inconsistency in the language.
> (Overall, as great as "uniform initialization" sounds on paper,
> in practice it causes a lot of headaches. At a very minimum they
> should have used a different syntax for initializer lists.)

I think a bit of inconsistency and ugly syntax is almost inevitable here 
- backwards compatibility makes it practically impossible to change 
existing behaviour.  I don't know how the language could have done 
anything better here.

[toc] | [prev] | [next] | [standalone]

#88323 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

31.12.2022 17:05 Juha Nieminen kirjutas:
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> Sure, these are probably specific to our codebase:
>>
>> -Wno-missing-field-initializers -Wno-unused-parameter
>> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
>>
>> The first one is there probably because we have many classes whose
>> members are often not initialized by the constructions, but later, by
>> the framework.
> 
> I think that using [[maybe_unused]] is better than disabling the warning
> because it more explicitly indicates that it being unused is not a mistake
> and the programmer was aware of it.

You are right in that the unused parameter warnings should be dealt 
case-by-case instead of a global compiler option. I guess there was no 
time or willingness to do that when the compiler suddenly started to 
spit out hundreds of such warnings, and after adding the global option 
there has been no motivation to do that.

Still, I'm not convinced [[maybe_unused]] is the best solution always. 
As far as I can see, this is meant more for conditional compilation, 
where a thing might be indeed sometimes used and sometimes not, 
depending on preprocessor macro definitions.

In my code, I get this warning mainly for virtual function overrides 
where some parameter is e.g. only used by 1 override of 10. And in those 
9 other overrides the parameter is not maybe unused, but definitely 
unused. Alas, by some reason there is no [[unused]] attribute.

In this scenario, I believe it might be better (i.e. more readable) to 
just delete or comment out the parameter name, it will have the same 
effect.

[toc] | [prev] | [next] | [standalone]

#88325 — Re: g++ -c -Werror -Weverything exercise_2_17.cpp

On 31/12/2022 17:50, Paavo Helde wrote:
> 31.12.2022 17:05 Juha Nieminen kirjutas:
>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> Sure, these are probably specific to our codebase:
>>>
>>> -Wno-missing-field-initializers -Wno-unused-parameter
>>> -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-parentheses
>>>
>>> The first one is there probably because we have many classes whose
>>> members are often not initialized by the constructions, but later, by
>>> the framework.
>>
>> I think that using [[maybe_unused]] is better than disabling the warning
>> because it more explicitly indicates that it being unused is not a 
>> mistake
>> and the programmer was aware of it.
> 
> You are right in that the unused parameter warnings should be dealt 
> case-by-case instead of a global compiler option. I guess there was no 
> time or willingness to do that when the compiler suddenly started to 
> spit out hundreds of such warnings, and after adding the global option 
> there has been no motivation to do that.
> 
> Still, I'm not convinced [[maybe_unused]] is the best solution always. 
> As far as I can see, this is meant more for conditional compilation, 
> where a thing might be indeed sometimes used and sometimes not, 
> depending on preprocessor macro definitions.
> 
> In my code, I get this warning mainly for virtual function overrides 
> where some parameter is e.g. only used by 1 override of 10. And in those 
> 9 other overrides the parameter is not maybe unused, but definitely 
> unused. Alas, by some reason there is no [[unused]] attribute.
> 
> In this scenario, I believe it might be better (i.e. more readable) to 
> just delete or comment out the parameter name, it will have the same 
> effect.
> 

That can often be the best choice - though of course "best" will depend 
on many things.

Another option is a cast to void - I believe most compilers treat that 
as considering the parameter "used" without generating any code.  You 
may feel a comment is warranted to explain what you are doing.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web