With " warnings as errors ", you don't want it to stop the debuging.

[Jeff-Relf.Me]

Mr ChrisV wrote:
> Relf's statements eschewing the importance of compiler warnings [ is stupid ].

Quoting myself:
http://Jeff-Relf.Me/C++CodingRules.HTM

  With " warnings as errors ", turn off these warnings:

     c4702: UnReachable code.

       A tempory "return" is needed, at times, when debugging.
       With " warnings as errors ", you don't want it to stop the debuging.

     c4100: unreferenced parameter.
     c4101: unreferenced local variable.
     c4189: local variable is initialized but not referenced.

       Variables get commented out, at times, when debugging.
       With " warnings as errors ", you don't want it to stop the debuging.
       UnUsed variables are informative, and might be needed again, later.

[Alf P. Steinbach]

On 24-May-17 3:00 PM, Jeff-Relf.Me@. wrote:
> [snip]

> Quoting myself:
> http://Jeff-Relf.Me/C++CodingRules.HTM
>
> With " warnings as errors ", turn off these warnings:
>
> c4702: UnReachable code.
>
> A tempory "return" is needed, at times, when debugging.
> With " warnings as errors ", you don't want it to stop the debuging.
>
> c4100: unreferenced parameter.
> c4101: unreferenced local variable.
> c4189: local variable is initialized but not referenced.
>
> Variables get commented out, at times, when debugging.
> With " warnings as errors ", you don't want it to stop the debuging.
> UnUsed variables are informative, and might be needed again, later.
>
>

For Visual C++, as of 15th June 2010:

https://alfps.wordpress.com/the-no_sillywarnings_please-h-file/

-------------------------------------------------------------------------------
// Copyright (c) Alf P. Steinbach, 2010.
// #include <progrock/cppx/compiler_specific/msvc/no_sillywarnings_please.h>

#ifndef PROGROCK_CPPX_COMPILERSPECIFIC_MSVC_NOSILLYWARNINGSPLEASE_H
#define PROGROCK_CPPX_COMPILERSPECIFIC_MSVC_NOSILLYWARNINGSPLEASE_H

#ifndef _MSC_VER
# error This file is specific to the MSVC (Microsoft Visual C++) compiler.
#endif

#ifndef CPPX_ALLOW_WP64
# // The /Wp64 option generates spurious warnings when a __w64 type
argument selects
# // a correct overload with non-__w64 formal argument type, i.e. for
<<. In newer
# // versions of MSVC this option is deprecated. It Really Annoyed a
lot of people!
# ifdef _Wp64
# error Do not use the /Wp64 option: use a 64-bit compiler to
detect 64-bit portability issues.
# endif
#endif

// The following are real warnings but are generated by almost all MS
headers, including
// standard library headers, so it's impractical to leave them on.
#pragma warning( disable: 4619 ) // there is no warning number 'XXXX'
#pragma warning( disable: 4668 ) // XXX is not defined as a
preprocessor macro

// The following are pure sillywarnings:
#pragma warning( disable: 4061 ) // enum value is not *explicitly*
handled in switch
#pragma warning( disable: 4099 ) // first seen using 'struct' now
seen using 'class'
#pragma warning( disable: 4127 ) // conditional expression is constant
#pragma warning( disable: 4217 ) // member template isn't copy
constructor
#pragma warning( disable: 4250 ) // inherits (implements) some member
via dominance
#pragma warning( disable: 4251 ) // needs to have dll-interface to be
used by clients
#pragma warning( disable: 4275 ) // exported class derived from
non-exported class
#pragma warning( disable: 4347 ) // "behavior change", function
called instead of template
#pragma warning( disable: 4355 ) // "'this': used in member
initializer list
#pragma warning( disable: 4428 ) // MSVC 9: universal-character-name
encountered in source
#pragma warning( disable: 4505 ) // unreferenced function has been
removed
#pragma warning( disable: 4510 ) // default constructor could not be
generated
#pragma warning( disable: 4511 ) // copy constructor could not be
generated
#pragma warning( disable: 4512 ) // assignment operator could not be
generated
#pragma warning( disable: 4513 ) // destructor could not be generated
#pragma warning( disable: 4610 ) // can never be instantiated user
defined constructor required
#pragma warning( disable: 4623 ) // default constructor could not be
generated
#pragma warning( disable: 4624 ) // destructor could not be generated
#pragma warning( disable: 4625 ) // copy constructor could not be
generated
#pragma warning( disable: 4626 ) // assignment operator could not be
generated
#pragma warning( disable: 4640 ) // a local static object is not
thread-safe
#pragma warning( disable: 4661 ) // a member of the template class is
not defined.
#pragma warning( disable: 4670 ) // a base class of an exception
class is inaccessible for catch
#pragma warning( disable: 4672 ) // a base class of an exception
class is ambiguous for catch
#pragma warning( disable: 4673 ) // a base class of an exception
class is inaccessible for catch
#pragma warning( disable: 4675 ) // resolved overload was found by
argument-dependent lookup
#pragma warning( disable: 4702 ) // unreachable code, e.g. in <list>
header.
#pragma warning( disable: 4710 ) // call was not inlined
#pragma warning( disable: 4711 ) // call was inlined
#pragma warning( disable: 4820 ) // some padding was added
#pragma warning( disable: 4917 ) // a GUID can only be associated
with a class, interface or namespace
#pragma warning( disable: 4996 ) // MSVC 9: a C std library function
has been "deprecated" (says MS)

#endif
-------------------------------------------------------------------------------


Cheers & hth.,

- Alf

[David Brown]

On 24/05/17 16:18, Alf P. Steinbach wrote:
> On 24-May-17 3:00 PM, Jeff-Relf.Me@. wrote:
>> [snip]
>> Quoting myself:
>> http://Jeff-Relf.Me/C++CodingRules.HTM
>>
>> With " warnings as errors ", turn off these warnings:
>>
>> c4702: UnReachable code.
>>
>> A tempory "return" is needed, at times, when debugging.
>> With " warnings as errors ", you don't want it to stop the
>> debuging.
>>
>> c4100: unreferenced parameter.
>> c4101: unreferenced local variable.
>> c4189: local variable is initialized but not referenced.
>>
>> Variables get commented out, at times, when debugging.
>> With " warnings as errors ", you don't want it to stop the
>> debuging.
>> UnUsed variables are informative, and might be needed again,
>> later.
>>
>>
>
> For Visual C++, as of 15th June 2010:
>
> https://alfps.wordpress.com/the-no_sillywarnings_please-h-file/
>

I don't use MSVC, but a brief look at your list there shows it includes
warnings whose equivalents in gcc are definitely useful in enforcing
good code quality. At the very least, you should be aware that your
list here is highly personal - those are not "silly warnings", they are
warnings that are triggered in /your/ code that /you/ think are
unnecessary. (Some of them are probably also "silly" in my opinion too
- but it is opinion and style, not some absolute rating.)

[Alf P. Steinbach]

No, the list was compiled with input from a much larger than noe clc++
community, at the time.

If you think some of those sillywarnings are not sillywarnings, then
you're doing Something Wrong™.

(Some of them are probably also "silly" in my opinion too
> - but it is opinion and style, not some absolute rating.)

No, it was, mostly, the consensus of the C++ community, at the time.

Some sillywarnings were added later.

I have somewhere a ditto header for g++, but /that/ one is just my
personal opinion.

[Scott Lurndal]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>On 24-May-17 4:23 PM, David Brown wrote:

>>
>> I don't use MSVC, but a brief look at your list there shows it includes
>> warnings whose equivalents in gcc are definitely useful in enforcing
>> good code quality. At the very least, you should be aware that your
>> list here is highly personal - those are not "silly warnings", they are
>> warnings that are triggered in /your/ code that /you/ think are
>> unnecessary.
>

I agree here with David. Many of those warnings indicate poor coding
style or outright bugs.

>No, the list was compiled with input from a much larger than noe clc++
>community, at the time.

"noe" is that norsk? or an anagram of 'one'?

>
>No, it was, mostly, the consensus of the C++ community, at the time.

What C++ community, at what time? At a bare minimum, that community
is restricted to those using MSVC and doesn't include the significant
C++ programming community that doesn't use MSVC.

One can't consider Usenet to be anything close to representative
of any community.

[Alf P. Steinbach]

On 24-May-17 5:11 PM, Scott Lurndal wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>> On 24-May-17 4:23 PM, David Brown wrote:
>
>>>
>>> I don't use MSVC, but a brief look at your list there shows it includes
>>> warnings whose equivalents in gcc are definitely useful in enforcing
>>> good code quality. At the very least, you should be aware that your
>>> list here is highly personal - those are not "silly warnings", they are
>>> warnings that are triggered in /your/ code that /you/ think are
>>> unnecessary.
>>
>
> I agree here with David. Many of those warnings indicate poor coding
> style or outright bugs.

We can discuss your opinion, which is wrong.

Mostly suppression of these warnings was, at the time, about being able
to use the highest warning level with warnings as errors. Otherwise
there would be an avalanche of warnings, from Microsoft's system
headers. Since then Visual C++ has got better at suppressing system
header warnings, but the list is still useful, for that purpose.

Your opinion is, like David's, apparently based on blissful ignorance:
not having used or not ordinarily using that compiler.

[Scott Lurndal]

I will say that I've not used Visual C++ ever. I did write a couple
device drivers for NT3.51 which used the Microsoft C compiler
(albeit using nmake from the command line).

If it takes your header file to make the compiler useful, then the
compiler is a POS.

[Bo Persson]

Have to agree with Alf here, these warnings are not useful as they
result in lots of false positives for perfectly legal code.

For example, if your class inherits from boost::non_copyable you
certainly don't want the warning "copy constructor could not be generated".

Some of them might be out of date for people not using MSVC9, but
otherwise it seems reasonable.

My own "silly list" includes things like:

// Sometimes the default copy constructor and operator=
// cannot be generated,
// specifically when the parent class has them hidden (private)
// to explicitly prohibit copying.
// warning C4511: copy constructor could not be generated
#pragma warning(disable: 4511)
// warning C4512: assignment operator could not be generated
#pragma warning(disable: 4512)

// warning C4522: 'class' : multiple assignment operators specified
// This warning is generated for the very valid combination
// (from <atomic>)
// type& operator=(const type&) = delete;
// type& operator=(const type&) volatile = delete;
#pragma warning(disable: 4522)

// The compiler very nicely optimizes away unneeded
// try-catch blocks in templates,
// and then warns about the code in the catch clause
// being unreachable...
// warning C4702: unreachable code
#pragma warning(disable: 4702)


Bo Persson

[Bo Persson]

No compiler is really widely useful with its default settings.

The difference is that with MSVC it is easier to use pragmas to modify
the defaults, and not option flags in a make-file.


Bo Persson

[Alf P. Steinbach]

On 24-May-17 8:12 PM, Bo Persson wrote:
> On 2017-05-24 19:48, Scott Lurndal wrote:
>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>> On 24-May-17 5:11 PM, Scott Lurndal wrote:

>> [snip]

>> If it takes your header file to make the compiler useful, then the
>> compiler is a POS.

Agree with Scott here, assuming that POS means something like PITA. :)

> No compiler is really widely useful with its default settings.

Agreed.

> The difference is that with MSVC it is easier to use pragmas to modify
> the defaults, and not option flags in a make-file.

There is partial support in g++ via its `#pragma GCC diagnostic`. See
<url: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html>. But
AFAIK not all g++ warnings have names that can be used to disable them.


Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<og4ka8$hkd$1...@dont-email.me> thusly:

>On 24-May-17 8:12 PM, Bo Persson wrote:
>> On 2017-05-24 19:48, Scott Lurndal wrote:
>>> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>>>> On 24-May-17 5:11 PM, Scott Lurndal wrote:
>>> [snip]
>>> If it takes your header file to make the compiler useful, then the
>>> compiler is a POS.
>
>Agree with Scott here, assuming that POS means something like PITA. :)

"Useful" is an exaggeration IMO. The compiler is useful whether or
not it produces these warnings. As Alf pointed out, they impact the
usefulness of saying "warnings are errors", which is why this header
makes the "warnings as errors" a useful switch. It is erroneous to
say that the entire compiler/IDE has no usefulness without this
header.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Robert Wessel]

On Wed, 24 May 2017 17:48:22 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

>I will say that I've not used Visual C++ ever. I did write a couple
>device drivers for NT3.51 which used the Microsoft C compiler
>(albeit using nmake from the command line).

FSVO "Visual C++". MS has never released any 32-bit C or C++ compiler
except under the "Visual C++" name. These have all, of course, had a
C mode. NT 3.51 DD development would likely have been done with MSVC
1.5 or 2.0.

[Bo Persson]

At least at the time of NT you could get a Device Driver Kit with only
the command line compiler and no Visual Studio.

Same compiler though.


Bo Persson

[Robert Wessel]

IIRC, VS didn't exist as a product at the time 3.51 was released, and
each of the languages came with (more or less) its own IDE.

OTOH, I simply don't remember how the DDK was packaged back them I
did install several, but if they came with the C compiler built in or
added on to a Visual C++ installation, I have no memory.

[Scott Lurndal]

To be fair, I did all my editing using vi on an SVR3 box, and just copied
the source over to the NT machine to compile and test them. The drivers
were for WORM (optical, pre-CD) drives and a WORM jukebox.

[David Brown]

(Scott, I read "noe" as "now", in the sense of "current". "noe" /is/ a
Norwegian word, meaning "something", but that would not make sense in
the context.)

>
> If you think some of those sillywarnings are not sillywarnings, then
> you're doing Something Wrong™.
>
>
> (Some of them are probably also "silly" in my opinion too
>> - but it is opinion and style, not some absolute rating.)
>
> No, it was, mostly, the consensus of the C++ community, at the time.
>
> Some sillywarnings were added later.
>
> I have somewhere a ditto header for g++, but /that/ one is just my
> personal opinion.
>

In addition to gcc's -Wall and -Wextra, I explicitly turn /on/ several
warnings that are the direct equivalent of some of the ones you are
disabling here. Some of the others I am less sure about, and many do
not have direct gcc equivalents. Note that this is primarily for my own
code - third-party code often does not stick to the same strict
standards as I do, and so I have to loosen my warnings for them.

For example, I think it is a /good/ thing to check that all enum values
are handled in a switch. That means that if I add a new value to an
enum, and I forget to handle it in a switch, I get a warning. Each bug
spotted by the compiler is a bug less to find in testing.

I don't put functions in my code that are not used - I write for small
embedded systems, and don't want to waste space.

If I mark a function as "inline", and it is not inlined, I want to know
about it. (But I don't care if a normal function /is/ inlined by the
compiler.)

If padding is added to a struct, I want to know about it.


It is probably fair to say that disabling most of the warnings on your
list would not be a problem to me. It is unlikely that they would be
triggered by my code (after all, most of what I write is C rather than
C++!). And I think if, for example, a copy constructor cannot be
generated for a class, then that is because of the way you have written
the class. It is only a problem if the copy constructor cannot be
generated, and you need to use it - /that/ is when there needs to be a
warning or error.

[Alf P. Steinbach]

On 25-May-17 10:39 PM, David Brown wrote:
>
> In addition to gcc's -Wall and -Wextra, I explicitly turn /on/ several
> warnings that are the direct equivalent of some of the ones you are
> disabling here. Some of the others I am less sure about, and many do
> not have direct gcc equivalents. Note that this is primarily for my own
> code - third-party code often does not stick to the same strict
> standards as I do, and so I have to loosen my warnings for them.

I agree wholeheartedly with you that reasonable warnings should be
turned on, in general. That was the purpose of the list: to allow one to
use the VC compiler with the highest normal warning level, /W4, without
getting bogged down in an avalanche of system header warnings. Today, if
I were addressing this area I would make a header that /turns on/ some
warnings that the below referenced Microsoft list says are turned off in
VC 2017, in particular the signed/unsigned mismatch warning C4389.

> For example, I think it is a /good/ thing to check that all enum values
> are handled in a switch. That means that if I add a new value to an
> enum, and I forget to handle it in a switch, I get a warning. Each bug
> spotted by the compiler is a bug less to find in testing.

This was, in 2010, a Visual C++ warning that generated false positives
for code like

enum class Enum{ a, b, c, d, e, f };

auto foo() -> Enum;

auto main() -> int
{
switch( foo() )
{
case Enum::a: return 10;
case Enum::b: return 20;
default:
break;
}
return 30;
}

When one uses `default:` in a `switch` then that means that one is
handling every other value. But Visual C++ didn't see it that way: the
VC designers thought that it was a good idea to warn about the use of
`default:`, for what if it had been placed there by, say, a copy/paste
error, or sumthin'?. Hence in 2010 it was a negative value sillywarning.

With Visual C++ 2017 that warning, C4061, has been /turned off/ by
default. Presumably for the same reason as my sillywarnings-list. See
the list at
<https://docs.microsoft.com/en-us/cpp/preprocessor/compiler-warnings-that-are-off-by-default>;
as it happens this warning is on top.

I think this shows that for this particular concrete example you're
arguing from ignorance, due to simply not having much experience with
this compiler and its idiosyncrasies.

> I don't put functions in my code that are not used - I write for small
> embedded systems, and don't want to waste space.
>
> If I mark a function as "inline", and it is not inlined, I want to know
> about it. (But I don't care if a normal function /is/ inlined by the
> compiler.)

`inline`'s effect on inlining of calls is just a hint. Its main purpose,
and its only guaranteed effect, is to ensure that a function can be
defined in a header; technically, that it can be defined in the same
way, with extern linkage, in multiple translation units. When the
keyword is used for that guaranteed effect, or when a member function is
defined in the class definition (which implicitly gives it `inline`),
you really don't want the compiler spewing out diagnostics about
ignoring the additional vague hint semantics.

So here you're evidently doing something wrong.

Where you want an all-out effort to inline a call (I think it's better
to let the compiler decide, but let's say profiling says that the
compiler didn't inline where it should, and that it's critical), use the
appropriate compiler specific magic invocation. Standard C++ doesn't
have that feature; relying on `inline` to do /that/ job is not portable.
But the compiler-specific can be wrapped in a macro for portability.

This warning, C4710, is also off by default in Visual C++ 2017.

> If padding is added to a struct, I want to know about it.

No, really, you don't. Padding is added to most structs. Only if you
have designated the struct as packed, is such a warning useful.

And also this warning, C4820, is one of those that now are off by default.

I.e. for the three warnings so far, Microsoft have, wisely IMHO, agreed
with the sillywarnings list. :-)

> It is probably fair to say that disabling most of the warnings on your
> list would not be a problem to me. It is unlikely that they would be
> triggered by my code (after all, most of what I write is C rather than
> C++!). And I think if, for example, a copy constructor cannot be
> generated for a class, then that is because of the way you have written
> the class.

No, that could be e.g. `boost::noncopyable`.

> It is only a problem if the copy constructor cannot be
> generated, and you need to use it - /that/ is when there needs to be a
> warning or error.

Yes, I agree, but Visual C++ has had a habit of emitting these
diagnostics whenever, as it looks from a purely local context ignoring
everything else, they /might/ apply.

[David Brown]

gcc helpfully distinguishes between -Wswitch, which warns about missing
enumeration cases /unless/ there is a default clause, and -Wswitch-enum
which will warn even if there is a default. -Wswitch is the useful one
in almost all cases. If gcc only had "-Wswitch-enum", then I'd agree it
is was silly, and only enable it manually (with pragmas) in situations
where it would be really helpful.

> With Visual C++ 2017 that warning, C4061, has been /turned off/ by
> default. Presumably for the same reason as my sillywarnings-list. See
> the list at
> <https://docs.microsoft.com/en-us/cpp/preprocessor/compiler-warnings-that-are-off-by-default>;
> as it happens this warning is on top.
>
> I think this shows that for this particular concrete example you're
> arguing from ignorance, due to simply not having much experience with
> this compiler and its idiosyncrasies.
>

This case is ignorance of the details - I have not claimed any knowledge
of the MSVC warnings beyond the comments in your list.

>
>> I don't put functions in my code that are not used - I write for small
>> embedded systems, and don't want to waste space.
>>
>> If I mark a function as "inline", and it is not inlined, I want to
>> know about it. (But I don't care if a normal function /is/ inlined by
>> the compiler.)
>
> `inline`'s effect on inlining of calls is just a hint. Its main purpose,
> and its only guaranteed effect, is to ensure that a function can be
> defined in a header; technically, that it can be defined in the same
> way, with extern linkage, in multiple translation units. When the
> keyword is used for that guaranteed effect, or when a member function is
> defined in the class definition (which implicitly gives it `inline`),
> you really don't want the compiler spewing out diagnostics about
> ignoring the additional vague hint semantics.

I do want these, yes - at least for my own code. If I declare a
function "inline", then I want it to be inlined by the compiler. If I
did not think it /could/ be inlined - for example, if I wanted to take
its address, or call it recursively - then I would not have marked it
"inline". I don't want functions declared in headers that result in
code generation on their own (excluding templates here). So if the
compiler is unable to inline a function that I have marked "inline", I
have made a mistake somewhere - either in how I use the function, what
the function does, or in labelling it "inline". To me, "inline" is as
much documentation to the reader as a hint to the compiler, and it
should match the compiler's viewpoint.

Of course other people can have a different opinion here - but to /me/,
warning on a failure to inline is a useful warning, not a silly one.

>
> So here you're evidently doing something wrong.
>
> Where you want an all-out effort to inline a call (I think it's better
> to let the compiler decide, but let's say profiling says that the
> compiler didn't inline where it should, and that it's critical), use the
> appropriate compiler specific magic invocation. Standard C++ doesn't
> have that feature; relying on `inline` to do /that/ job is not portable.
> But the compiler-specific can be wrapped in a macro for portability.

I use the appropriate compiler-specific "magic words" sometimes to force
inlining. A typical case is when I know that constant propagation will
mean that a function that /looks/ big and complex (and therefore the
compiler might decide against inlining) will turn into something small
and short in practice. Or perhaps the function is to be used within
critical sections of some sort (like interrupt functions - I work on
low-level embedded systems) and I want to keep it as fast as possible.

That is a different situation, however.

(And as I say, I am quite happy to let the compiler inline functions
that are /not/ marked inline, and don't feel a need for a warning there.
Indeed, I /expect/ the compiler to do such inlining, especially for
local functions that are only called once.)

>
> This warning, C4710, is also off by default in Visual C++ 2017.
>
>
>> If padding is added to a struct, I want to know about it.
>
> No, really, you don't. Padding is added to most structs. Only if you
> have designated the struct as packed, is such a warning useful.

Yes, really, I /do/ want this warning. And /no/, I don't want to mark
the struct as "packed". Feel free to express your own opinions, but
please do not try to tell me /my/ opinions. In my world, precise
control of exactly how data is organised can be important - it is
important enough that I prefer to have this warning and explicitly add
"padding" fields to my structs and necessary. I don't /always/ use this
warning, but I often do.


Now, I fully agree that it is unlikely that /you/ want this warning.
For user-mode programming on a large system, it is going to be rare that
you need this kind of control of structure layout. And you will get
massive numbers of false positives from common OS and API include files.
So for the typical MSVC user, it is probably useless. In the few cases
where it makes sense, you can enable it temporarily with pragmas.

My point is merely that this warning, viewed as a static analysis tool,
is not "silly" or "useless" in C and C++ development - it has its place.

>
> And also this warning, C4820, is one of those that now are off by default.
>
> I.e. for the three warnings so far, Microsoft have, wisely IMHO, agreed
> with the sillywarnings list. :-)
>
>
>> It is probably fair to say that disabling most of the warnings on your
>> list would not be a problem to me. It is unlikely that they would be
>> triggered by my code (after all, most of what I write is C rather than
>> C++!). And I think if, for example, a copy constructor cannot be
>> generated for a class, then that is because of the way you have
>> written the class.
>
> No, that could be e.g. `boost::noncopyable`.

Presumably, this class is written specifically in a way to make it
non-copyable and to mean that "a copy constructor cannot be generated
for this class". Maybe I was not quite clear in how I expressed myself,
because we appear to agree.

>
>
>> It is only a problem if the copy constructor cannot be generated, and
>> you need to use it - /that/ is when there needs to be a warning or error.
>
> Yes, I agree, but Visual C++ has had a habit of emitting these
> diagnostics whenever, as it looks from a purely local context ignoring
> everything else, they /might/ apply.

Indeed. It sounds to me that this example /is/ a "silly warning".

[Bo Persson]

Right, so MSVC similarly has

C4061 enumerator 'identifier' in a switch of enum 'enumeration' is not
explicitly handled by a case label

C4062 enumerator 'identifier' in a switch of enum 'enumeration' is not
handled


And the first one is "the silly one" we turn off, unless we also have a
silly coding standard that forbids use of 'default:'.



Bo Persson

[David Brown]

Fair enough.

However, I would call a coding standard that forbids the use of default
"questionable", not "silly". Perhaps it is silly in the context of
typical Windows MSVC development - but there are other kinds of
programming, with different requirements and different appropriate
coding standard rules. And there are also types of programming where it
is appropriate to require that all enum cases are covered, /and/ you
have a default case.

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 24/05/17 17:05, Alf P. Steinbach wrote:

>> No, the list was compiled with input from a much larger than noe clc++
>> community, at the time.
>
>(Scott, I read "noe" as "now", in the sense of "current". "noe" /is/ a
>Norwegian word, meaning "something", but that would not make sense in
>the context.)
>

Munga Tusa Takk, David. While my grandparents all grew up speaking Norwegian,
I'm limited to a literal handful of words myself (which I probably can't spell :-)

[David Brown]

It is a language of limited use, unless you happen to live in Norway.

And you are right - you can't spell your Norwegian words :-)

[Alf P. Steinbach]

Well, if your the books about Nuwen – not about STL, though he chose to
use that name for his site where offers a MinGW distro – namely, Vernon
Vinge's “A Deepness in the Sky”, “A Fire Upon the Deep” and “The
Children of the Sky”, especially the middle one of these works, you will
discover that Norwegian is the /lingua franca/ of the Usenet-like
communications network in the upper galactic reaches.

Of course, even with IPv6 and IDNA we here on Earth still don't have the
necessary addressing ability to easily access that network, so it's
understandable that few here are currently familiar with it.


Cheers!,

- Alf