Re: [lmi] Removing comment induces compiler error

[Vadim Zeitlin]

On Mon, 6 Mar 2017 02:47:52 +0000 Greg Chicares <address@hidden> wrote:

[...my proposal to use a pragma to disable warning in the code using wx...]
GC> No, thanks. This method does have its advantages, but:
GC> 
GC>   "If possible, #pragmas are best avoided." -- TC++PL4, 12.6.3

 I strongly disagree with this. I don't doubt the expertise of the author
of this quote, but it had obviously been written before the appearance of
"#pragma diagnostic" which is very useful IMNSHO. I see absolutely no
reason to prefer disabling warnings outside of the code generating them and
very good reasons for doing it in the code itself. Moreover, there are many
cases in which pragma allows to do things impossible to do with compiler
options, e.g. disable some warning only for the code in the header itself,
but leave it enabled for the code in the file including the header.

GC> In this case, correctness would depend on a pragma.

 No, it wouldn't, why? The code is exactly the same, it's just the warning
that is suppressed.

GC> We should have fewer pragmas, not more.

 I don't see any rationale for this dogma (well, yes, it's an oxymoron).
Different pragmas are very different and some of them probably should be
avoided, but this one ("GCC diagnostic") is definitely useful. Frankly, I
don't see any reason for this pragmaphobia.


 Anyhow, there are, of course, other ways of working around the problem.
But I'd very much like to avoid anything using magic in the makefiles,
we've just had a great example of how deeply confusing it can be. My
preferred solution remains the one based on using the pragma, but I'd also
prefer dropping -Wcast-qual completely rather than complicating makefiles
even further to deal with this case.

 Of course, ideal would be to make wxWidgets headers compile with
-Wcast-qual, I guess it's a useful warnings (albeit marginally so IMO).
However it seems it might be not trivial to achieve this. Please let me
know if you'd like me to try...

VZ