With newer gcc versions I often get warnings that inlining failed for auto-generated functions. Is this a bug or is the use of auto-generated functions not recommended for slightly larger structures?

Example: with

struct Recording
{ Guid id = Guid::empty;
xStringD0 artist;
xStringD0 title;
double duration = 0.;
float score = 0.;
unsigned release_count = 0;
std::unique_ptr<const Release[]> releases;
};

I get warnings like

warning: inlining failed in call to ‘Recording& Recording::operator=(Recording&&) noexcept’: --param
max-inline-insns-single limit reached [-Winline]

- Guid is in fact char[16],
- xStringD0 is a (smart) pointer to a string with move assignment
(noexcept, not constexpr because std::swap isn't),
- unique_ptr should be also just a pointer with move semantics.

OK, there are 3 members of non-POD type, any maybe inlining is not
adequate. But shouldn't the compiler just take the best implementation?
Or are default generated functions necessarily forced to be inline?
In the latter case: how do I avoid to implement this functions
explicitly. It is too easy to forget a new member in such implementations.

(C++14, gcc 13.3)


Marcel

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: MB-NET.NET for Open-News-Network e.V. (3:633/280.2@fidonet)

On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:

OK, there are 3 members of non-POD type, any maybe inlining is not
adequate. But shouldn't the compiler just take the best implementation?
Or are default generated functions necessarily forced to be inline?

It might be a simple consequence of a lazy implementation.

The standard says that an implicitly declared copy/move assignment
operator is an _inline_ public member of its class. So, it is quite
possible that GCC just marks such functions internally as "inline". And
later it issues a diagnostic when it fails to actually substitute some
call, just like it would for any other inline function.

Obviously, this diagnostic would be more appropriate for situations when inlining was explicitly requested (or hinted at) by the user. But it is
quite possible that at that point GCC simply can't tell inlining
requested by the user from inlining of implicitly declared special
member functions.

--
Best regards,
Andrey

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Subject: Re: Inlining of auto generated move constructor/assignment failed
[solved]

Am 21.08.25 um 07:58 schrieb Andrey Tarasevich:

On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:

OK, there are 3 members of non-POD type, any maybe inlining is not
adequate. But shouldn't the compiler just take the best implementation?
Or are default generated functions necessarily forced to be inline?

It might be a simple consequence of a lazy implementation.

It turned out that this kind of warning of gcc is normally turned off
and not even activated by -Wextra. But some guy managed to explicitly
enable this warning in a dark corner of the custom automake macros of
the project. -.-


Marcel

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: MB-NET.NET for Open-News-Network e.V. (3:633/280.2@fidonet)

On Sat, 23 Aug 2025 10:41:12 +0200
Marcel Mueller <news.5.maazl@spamgourmet.org> gabbled:

Am 21.08.25 um 07:58 schrieb Andrey Tarasevich:

On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:

OK, there are 3 members of non-POD type, any maybe inlining is not
adequate. But shouldn't the compiler just take the best implementation?
Or are default generated functions necessarily forced to be inline?

It might be a simple consequence of a lazy implementation.

It turned out that this kind of warning of gcc is normally turned off
and not even activated by -Wextra. But some guy managed to explicitly
enable this warning in a dark corner of the custom automake macros of
the project. -.-

As an aside, the inconsistency of gcc cmd line options wrt warnings and between versions really pisses me off. It shouldn't even need -Wextra (or -pedantic) if I've already given it -Wall because all funnily enough means all, it doesn't mean all except some random ones - which seem to change between versions - it won't show unless you give extra options.

Until recently I was compiling all my straight C code on gcc v4 because it
gave quite useful warnings that later versions wouldn't show no matter what options you gave them.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 23/08/2025 11:14, boltar@caprica.universe wrote:

On Sat, 23 Aug 2025 10:41:12 +0200
Marcel Mueller <news.5.maazl@spamgourmet.org> gabbled:

Am 21.08.25 um 07:58 schrieb Andrey Tarasevich:

On Tue 8/19/2025 1:33 PM, Marcel Mueller wrote:

OK, there are 3 members of non-POD type, any maybe inlining is not
adequate. But shouldn't the compiler just take the best implementation? >>>> Or are default generated functions necessarily forced to be inline?

It might be a simple consequence of a lazy implementation.

It turned out that this kind of warning of gcc is normally turned off
and not even activated by -Wextra. But some guy managed to explicitly
enable this warning in a dark corner of the custom automake macros of
the project. -.-

As an aside, the inconsistency of gcc cmd line options wrt warnings and between
versions really pisses me off. It shouldn't even need -Wextra (or - pedantic) if
I've already given it -Wall because all funnily enough means all, it
doesn't mean all except some random ones - which seem to change between versions - it won't show unless you give extra options.

Until recently I was compiling all my straight C code on gcc v4 because it gave quite useful warnings that later versions wouldn't show no matter what options you gave them.

I think you have misunderstood several things here.

gcc is an old project - it has been around for something like four
decades, and changed enormously since its early days. Perhaps "-Wall"
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. "-Wall" has, for a very long time, meant "warnings that are
suitable for a wide range of programs". Warnings that are triggered by
common code constructs - whether the code is right or wrong - are rarely
added to the set of "-Wall" warnings because they could mess up build
scripts for existing code (especially if the build has "-Werror" to turn warnings into errors).

"-Wextra" adds some more warnings that many people find useful. Many of
these are more controversial - for example, some people like to be
warned about missing names for parameters, others think such a warning
is counter-productive.

Some warnings are enabled by default (such as "-Wimplicit-int"), others
are only enabled by explicit flags (such as "-Wdouble-promotion").

"-pedantic" (or "-Wpedantic") is a special case - it asks gcc to be as
close to a specified C or C++ standard as it can.


Usually new versions of gcc add new warnings, but occasionally warning
flags are removed. One that I missed when it was removed was a warning
about dead code elimination. But it was removed for good reason. In
earlier compiler versions, dead code elimination was a relatively simple matter in one optimisation pass, and the warning could be implemented
easily enough and give accurate information. In later versions, dead
code elimination could occur in multiple places and in complex ways
(such as in combination with code duplication or re-arrangements),
making it increasingly hard to maintain and increasingly inaccurate. In addition, as gcc's optimisations got better, there were more and more circumstances in which code could be eliminated as "dead" - it was not
giving people useful information, so it was removed.


The decisions about what flags are included in "-Wall" and/or "-Wextra",
and when flags are added or removed in gcc, are not random or
inconsistent. They are made carefully, and most of the discussions are publicly available in the mailing lists and bug tracker comments. When
flags are added to -Wall, large swaths of code (biased, reasonably
enough, towards open source code for *nix) are tested to see if there
are conflicts with existing makefiles and other build scripts.
Decisions are made by weighing up the inconvenience of breaking existing builds or giving false positives and the benefits of making it easier
for developers to find problems with their code.


None of this is particularly special to gcc. If you have used any other compiler over a range of versions, you will likely have seen warnings
and other options come and go (I know I have). gcc has more warnings
than most compilers, but clang has even more. It also has a compiler
option "-Weverything" that really does enable all warnings. It is only
ever used for testing, or for fun, because no real-world program will
pass without triggering some false positive.






--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.

suitable for a wide range of programs". Warnings that are triggered by >common code constructs - whether the code is right or wrong - are rarely >added to the set of "-Wall" warnings because they could mess up build >scripts for existing code (especially if the build has "-Werror" to turn >warnings into errors).

And why is that a bad idea? Perhaps some hidden bugs have been found. If
you don't want that behaviour then don't upgrade the compiler.

and other options come and go (I know I have). gcc has more warnings
than most compilers, but clang has even more. It also has a compiler
option "-Weverything" that really does enable all warnings. It is only

Didn't know about Weverything, just tried it and its actually found a minor bug in a program I'm working on atm.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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 warning for "printf(s);" instead of "printf("%s", s);" ? Do you want a warning for all "switch" statements which don't have a "default" case?
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?

There are lots of warnings in gcc, and there are more in every new
version. Many are good, general warnings that can be helpful to a wide
range of people - these will typically be added to "-Wall" or "-Wextra".
Many are more obscure, and will be useful only to a small number of
people in niche circumstances.

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.

Good use of static warnings is very helpful in software development.
But /good/ use does not mean /blind/ use. The flags that are
appropriate will depend on the code, the programmer, the project. For
most of my own code, I start with "-Wall -Wextra", then turn off a few warnings that I find inappropriate, and enable a fair number of extra warnings. The selection is tuned with thought, consideration and
testing to give the best automatic checking I can get with minimal risk
of false positives - then I can treat warnings as errors that must be
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.

suitable for a wide range of programs".ÿ Warnings that are triggered
by common code constructs - whether the code is right or wrong - are
rarely added to the set of "-Wall" warnings because they could mess up
build scripts for existing code (especially if the build has "-Werror"
to turn warnings into errors).

And why is that a bad idea? Perhaps some hidden bugs have been found. If
you don't want that behaviour then don't upgrade the compiler.

People do not always have tight control of which compiler is used for
the code they write. (Some people do - /I/ do - but most do not.)

Warnings generated by toolchains are not synonymous with bugs in the
code. They are an indication that there /might/ be a problem in the
code, or the code might be written in a way that /could/ be considered
higher risk for bugs during development or maintenance. If a warning is triggered on "while (x = foo()) ...", it might have found a bug, or it
might have been perfectly correct code doing exactly what the programmer intended.

It can certainly be a good idea to run old code through newer and more advanced static error checkers, to help find old latent issues. But it
needs to be done with care and effort by people who can see if you are actually dealing with a problem in the code or simply a different style
of writing the code. This takes time and money - and it is not
necessarily an efficient use of those resources.

and other options come and go (I know I have).ÿ gcc has more warnings
than most compilers, but clang has even more.ÿ It also has a compiler
option "-Weverything" that really does enable all warnings.ÿ It is only

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.




--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 8/24/2025 5:45 AM, David Brown wrote:

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

[...]

x = y + 2.5

Actually, sometimes I want a warning wrt 2.5 vs 2.5f...


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 8/24/2025 12:56 PM, Chris M. Thomasson wrote:

On 8/24/2025 5:45 AM, David Brown wrote:

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

[...]

x = y + 2.5

Actually, sometimes I want a warning wrt 2.5 vs 2.5f...

Let me clarify:

float x = 0;
float y = 0;

x = y + 2.5;

I sometimes want a warning on the 2.5 instead of 2.5f. Even the 0 vs 0.f


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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!

warning for "printf(s);" instead of "printf("%s", s);" ? Do you want a

Why would that produce a warning?

warning for all "switch" statements which don't have a "default" case?

Happens already.

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.

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.

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.

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.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 24/08/2025 21:56, Chris M. Thomasson wrote:

On 8/24/2025 5:45 AM, David Brown wrote:

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

[...]

x = y + 2.5

Actually, sometimes I want a warning wrt 2.5 vs 2.5f...

Exactly - /sometimes/ people want that kind of warning, which is why gcc
has it. It is typically useful for targets where there is hardware
support for single-precision floating point, but not for
double-precision floating point. It can also be helpful where there
might be significant differences in performance, perhaps due to
vectorisation.

But most people are not at all interested in such a warning, and prefer
not to clutter their code with "f" suffixes.

All these unusual warnings are useful to /some/ people - but it is very unlikely that any one person will want /all/ of these warnings enabled
at the same time, for the same code.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2025-08-24, boltar@caprica.universe <boltar@caprica.universe> wrote:

On Sun, 24 Aug 2025 14:45:12 +0200
David Brown <david.brown@hesbynett.no> gabbled:

warning for "printf(s);" instead of "printf("%s", s);" ? Do you want a

Why would that produce a warning?

'printf(s);' can lead to surprises when s contains '%'.

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Reply-To: slp53@pacbell.net

boltar@caprica.universe writes:

On Sun, 24 Aug 2025 14:45:12 +0200

warning for "printf(s);" instead of "printf("%s", s);" ? Do you want a

Why would that produce a warning?

if "s" has a format specifier (e.g. '%s'), it can cause an
SIGBUS/SIGSEGV (or be used as a vector for malware).

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)

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



--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Mon, 25 Aug 2025 16:36:01 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 24/08/2025 22:42, boltar@caprica.universe wrote:

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

-Wall should have continued to mean all as compiler versions progressed.
Other warning options could have been introduced to keep the output similar
to earlier compiler versions or alternatively a flag to compile as an older version.

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.

No, you're making a Big Deal out of lots of warnings when a standard
error dump from gcc can be pages long and utterly useless.

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

A syntax error is a syntax error. Templates should make no difference.

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

Using that logic I shouldn't post on this group at all until i've read
the latest C++ specification from start to finish.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 25/08/2025 22:01, boltar@battlestar-galactica.com wrote:

On Mon, 25 Aug 2025 16:36:01 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 24/08/2025 22:42, boltar@caprica.universe wrote:

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

-Wall should have continued to mean all as compiler versions progressed. Other warning options could have been introduced to keep the output similar to earlier compiler versions or alternatively a flag to compile as an older version.

Certainly the gcc developers could have taken other paths here. They
could have said "You know that old "-Wall" flag you all find useful?
Well, now we are going to make it useless, and you'll have to start
using other flags instead if you want a practical selection of
warnings." That would have kept the name "all" meaning "all". I'm
happy that they made a different decision, but of course no choice of
flags, names, or collections of warnings is going to please everyone.

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.

No, you're making a Big Deal out of lots of warnings when a standard
error dump from gcc can be pages long and utterly useless.

/I/ am not the one making a big deal out of anything. /You/ are getting
your knickers in a twist because "-Wall" doesn't mean enable absolutely
all warning flags the compiler supports. I am happy enough with the
warning flags gcc has (they are not perfect, but good enough for most of
my needs - within the limits of compiler static error detection
technology). I am happy enough with the template error messages - they
are sometimes hard to read, but have improved over the years, and I have
so far managed to figure out the problems in my code.

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

A syntax error is a syntax error. Templates should make no difference.

And a tautology is a tautology. The things leading to warnings or
errors with templates are often something other than syntax errors -
that's why it is difficult (for compilers or humans) to figure out where
the mistake actually occurs, which is why error messages are so long and complicated. There are many other ways in C and C++ where a tiny
mistake in one place can lead to piles of warnings and errors elsewhere
- it's part of the fun of coding, and is far from a solved problem.

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

Using that logic I shouldn't post on this group at all until i've read
the latest C++ specification from start to finish.

Warning flags for a particular compiler are not part of the C++ standards.

But if you are going to get worked up about warnings in a particular
compiler, I think it makes sense to at least read a bit of the relevant compiler manual page.



--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Tue, 26 Aug 2025 09:06:23 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 25/08/2025 22:01, boltar@battlestar-galactica.com wrote:

-Wall should have continued to mean all as compiler versions progressed.
Other warning options could have been introduced to keep the output similar >> to earlier compiler versions or alternatively a flag to compile as an older >> version.

Certainly the gcc developers could have taken other paths here. They
could have said "You know that old "-Wall" flag you all find useful?
Well, now we are going to make it useless, and you'll have to start
using other flags instead if you want a practical selection of
warnings." That would have kept the name "all" meaning "all". I'm

"You know that old -Wall flag that used to show all the warnings? Well now its not going to any more, good eh? You won't know which ones we've left out and they might change with each release, but here's a new bunch of -W flags which will also change meaning in the future. Have fun with your build!"

No, you're making a Big Deal out of lots of warnings when a standard
error dump from gcc can be pages long and utterly useless.

/I/ am not the one making a big deal out of anything. /You/ are getting >your knickers in a twist because "-Wall" doesn't mean enable absolutely

I originally posted a single short paragraph on the subject. You're the
one responding with pages defending gcc. Are you on the dev team or
something?

tl;dr


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 26/08/2025 20:30, boltar@battlestar-galactica.com wrote:

On Tue, 26 Aug 2025 09:06:23 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 25/08/2025 22:01, boltar@battlestar-galactica.com wrote:

-Wall should have continued to mean all as compiler versions progressed. >>> Other warning options could have been introduced to keep the output
similar
to earlier compiler versions or alternatively a flag to compile as an
older
version.

Certainly the gcc developers could have taken other paths here.ÿ They
could have said "You know that old "-Wall" flag you all find useful?
Well, now we are going to make it useless, and you'll have to start
using other flags instead if you want a practical selection of
warnings."ÿ That would have kept the name "all" meaning "all".ÿ I'm

"You know that old -Wall flag that used to show all the warnings? Well
now its not going to any more, good eh? You won't know which ones we've
left out and they might change with each release, but here's a new bunch
of -W flags which will also change meaning in the future. Have fun with
your build!"

You can read what I wrote, explaining things to you.

Or you can read the relevant page in the gcc manual - it is not
difficult to understand.

Or you can remain stubbornly and wilfully ignorant and make a fool of
yourself crying about something that is only a problem in your own mind.

No, you're making a Big Deal out of lots of warnings when a standard
error dump from gcc can be pages long and utterly useless.

/I/ am not the one making a big deal out of anything.ÿ /You/ are
getting your knickers in a twist because "-Wall" doesn't mean enable
absolutely

I originally posted a single short paragraph on the subject. You're the
one responding with pages defending gcc. Are you on the dev team or something?

My apologies for being helpful and informative. I'll try not to let it
happen again.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Tue, 26 Aug 2025 22:49:39 +0200
David Brown <david.brown@hesbynett.no> wrote:

Or you can read the relevant page in the gcc manual - it is not
difficult to understand.

Right, because everyone reads the compiler manual before they start on a project. Just the list of warning flags alone take up almost a page and
thats with 2 or 3 on each line.

Or you can remain stubbornly and wilfully ignorant and make a fool of >yourself crying about something that is only a problem in your own mind.

Those straw men of yours deserve a pay rise.

I originally posted a single short paragraph on the subject. You're the
one responding with pages defending gcc. Are you on the dev team or
something?

My apologies for being helpful and informative. I'll try not to let it >happen again.

You're never ever just "being helpful and informative". You always throw in
a nice dose of patronisation and subtle ad hominems as the icing on the cake.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 8/24/2025 11:19 PM, David Brown wrote:

On 24/08/2025 21:56, Chris M. Thomasson wrote:

On 8/24/2025 5:45 AM, David Brown wrote:

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

[...]

x = y + 2.5

Actually, sometimes I want a warning wrt 2.5 vs 2.5f...

Exactly - /sometimes/ people want that kind of warning, which is why gcc
has it.ÿ It is typically useful for targets where there is hardware
support for single-precision floating point, but not for double-
precision floating point.ÿ It can also be helpful where there might be significant differences in performance, perhaps due to vectorisation.

But most people are not at all interested in such a warning, and prefer
not to clutter their code with "f" suffixes.

All these unusual warnings are useful to /some/ people - but it is very unlikely that any one person will want /all/ of these warnings enabled
at the same time, for the same code.

Exactly. Nice. Thanks David. :^)

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)