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

Groups > comp.lang.c++ > #122654

Re: Inlining of auto generated move constructor/assignment failed

Show all headers | View raw

On 24/08/2025 22:42, boltar@caprica.universe wrote:
> On Sun, 24 Aug 2025 14:45:12 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 23/08/2025 16:26, boltar@caprica.universe wrote:
>>> On Sat, 23 Aug 2025 16:15:03 +0200
>>> David Brown <david.brown@hesbynett.no> gabbled:
>>>> meant "all warnings" when it was first introduced, but these days 
>>>> there are hundreds of warning flags in gcc, and /nobody/ wants them 
>>>> all enabled.
>>>
>>> Presumably "nobody" is defined in a similar way as "all". It almost 
>>> no one
>>> but some people will. I'm one of them.
>>
>> I very much doubt that you are.
>>
>> Do you want a warning when you write "float x, y; x = y + 2.5;" ?  Do 
>> you want a warning when you write "char x; x = x + 1;" ?  Do you want a 
> 
> Do I want a warning about using uninitialised variables? Umm, let me 
> think...
> .. yes please!

Yes, of course - those are obvious (but I should have been clear about 
that).  I meant warnings on promotion of single-precision float to 
double-precision (in "x = y + 2.5;") and warnings about converting "int" 
to "char" in "x = x + 1;".

These are both useful in some types of programming, but not in most 
programming.

> 
>> warning for "printf(s);" instead of "printf("%s", s);" ?  Do you want a 
> 
> Why would that produce a warning?

You get that if you have "-Wformat-security" enabled.  Some programs get 
strings from an external source (such as files of messages in different 
languages).  If these are used as the first parameter of a printf() 
without careful sanitisation, they could be an attack surface by causing 
stack corruption.

Some people (such as myself) want warnings on double precision 
promotion, typically because they are using small limited 
microcontrollers.  Others want extra security on printf, typically 
because they read the format strings from external sources.  Very few 
people will want both.

> 
>> warning for all "switch" statements which don't have a "default" case? 
> 
> Happens already.

No it doesn't, unless you enable it specifically (on gcc anyway - I 
can't answer for clang or other tools).  "-Wswitch-default" is not 
enabled by "-Wall", "-Wextra", or by default.

> 
>> Do you want a warning on "int * p = 0;" ?  Do you want to warn about 
>> constructs that are not present in C or C++ standards other than the 
>> one you have chosen?
> 
> Yes, otherwise I wouldn't have specified a particular version.

The warning on "int * p = 0;" occurs if you have 
"-Wzero-as-null-pointer-constant" enabled.  Most C and C++ programmers 
are quite happy to use the literal 0 as a null pointer constant, but 
some consider it risky and want a warning, forcing the use of NULL or 
nullptr.

As for warnings about incompatibilities across standards versions, I 
think you have completely missed the point.

If I want to write code in C11, I write "-std=c11", and I write my code 
in C11.  I have picked that standard because I want to use features that 
are in C11 but not in C99 or earlier versions.  I am not interested in 
whether or not my code can also be compiled with C99 or C90.  I /might/ 
be interested in known compatibility issues with C17 or C23.  Similarly 
for C++ standards.  I suspect the same applies to you.

So I do not want warning flags telling me about using features that are 
not available in different standards, or that my use of "auto" in C23 or 
C++11 is incompatible with its use in earlier standards.  I do not want 
warnings that my C code is not compatible with C++ - if I had wanted C++ 
compatibility, I would have written C code.

Of course some people /do/ want to write code that is compatible across 
a range of standards, so the various "-Wxxx-compat" flags in gcc are 
helpful to them.  It is highly unlikely, however, that they will want 
all these flags on at the same time.

> 
>> Of course you are free to enable as many warnings as you like when you 
>> use gcc.  But before the gcc developers would bother implementing a 
>> "-Wabsolutely-everything" flag, they'd have to be persuaded that it 
>> would actually be useful to developers, worth the effort of 
>> implementing it, and worth the cost of the consequences of it (such a 
>> flag would limit the possibilities for flags that are not simply 
>> on/off).  I have seen discussions on the gcc mailing lists about a 
>> clang-style "-Weverything" flag for gcc, and read about why it is 
>> considered something of a joke flag in clang and only really of use 
>> when testing the compiler.
> 
> "all" should mean all, not almost all, or the ones considered useful.
> There was nothing stopping them using a different flag, eg -Wstandard
> or something like that for the kind of warnings considered useful.
> 

Then "-Wall" would be useless.

And yes, there /are/ things stopping gcc developers from changing flag 
names without very good reason - it is effort on their part that could 
be better spent on useful things, and it is effort on the part of all 
their users that would then have to change their build scripts and flags 
to match the pointless changes.

I have explained to you why "-Wall" has the name it does, and what it 
means.  I have explained why it does /not/ mean "all warnings", and why 
enabling "all warnings" would be of no serious use to anyone.  If you 
want to stay upset about this and continue to be annoyed about the name 
of the flag, that's your choice - but at least you should no longer be 
doing so from a position of ignorance.  And if you want to file a bug 
about it in the gcc development bug tracker, or write a patch for gcc to 
get the flag names you want, you are free to do so.


>> handled in some way, and not just ignored.  A "give me everything" 
>> flag that floods the output with false positives is only marginally 
>> better than no warnings at all.
> 
> Gcc standard warnings have nothing on the gibberish the C++ compiler 
> spits out
> when there's a template error. Why the compiler writers think 3 pages of 
> unintelligable crap is a useful tool in order to find what usually turns 
> out
> to be a simple typo i have no idea. Clang is far better , though still far
> from perfect.
> 

That is a red herring, completely irrelevant to the argument you have 
been trying to make.

But it is also an issue that every C++ compiler has had trouble with 
since the dawn of C++ templates.

And like many C++ compilers, gcc has been getting steadily better at 
this, with later versions give better (or at least, less bad) error 
messages than earlier versions.  Some compiler options can help tune 
behaviour to suit the user.  You can also combine gcc's newer parseable 
error formats with some IDE's to get a clearer picture.  And you can use 
concepts (C++23) to significantly improve template error handling.

>>> Didn't know about Weverything, just tried it and its actually found a 
>>> minor bug
>>> in a program I'm working on atm.
>>
>> Then you might want to look at the available warning options in 
>> whatever compiler(s) you use, and start enabling them in your build 
>> system.
> 
> Life is too short to google all possible warning flags and figure out which
> ones I need.
> 

But it is long enough to rant about how the warning flags don't suit 
your needs?  Okay...

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Inlining of auto generated move constructor/assignment failed Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-08-19 22:33 +0200
  Re: Inlining of auto generated move constructor/assignment failed Andrey Tarasevich <noone@noone.net> - 2025-08-20 22:58 -0700
    Re: Inlining of auto generated move constructor/assignment failed [solved] Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-08-23 10:41 +0200
      Re: Inlining of auto generated move constructor/assignment failed boltar@caprica.universe - 2025-08-23 09:14 +0000
        Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-23 16:15 +0200
          Re: Inlining of auto generated move constructor/assignment failed boltar@caprica.universe - 2025-08-23 14:26 +0000
            Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-24 14:45 +0200
              Re: Inlining of auto generated move constructor/assignment failed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-24 12:56 -0700
                Re: Inlining of auto generated move constructor/assignment failed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-24 13:10 -0700
                Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-25 08:19 +0200
                Re: Inlining of auto generated move constructor/assignment failed "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-27 16:34 -0700
              Re: Inlining of auto generated move constructor/assignment failed boltar@caprica.universe - 2025-08-24 20:42 +0000
                Re: Inlining of auto generated move constructor/assignment failed Ike Naar <ike@sdf.org> - 2025-08-25 06:52 +0000
                Re: Inlining of auto generated move constructor/assignment failed scott@slp53.sl.home (Scott Lurndal) - 2025-08-25 14:27 +0000
                Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-25 16:36 +0200
                Re: Inlining of auto generated move constructor/assignment failed boltar@battlestar-galactica.com - 2025-08-25 20:01 +0000
                Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-26 09:06 +0200
                Re: Inlining of auto generated move constructor/assignment failed boltar@battlestar-galactica.com - 2025-08-26 18:30 +0000
                Re: Inlining of auto generated move constructor/assignment failed David Brown <david.brown@hesbynett.no> - 2025-08-26 22:49 +0200
                Re: Inlining of auto generated move constructor/assignment failed boltar@battlestar-galactica.com - 2025-08-27 15:39 +0000

csiph-web