RFC: Avoiding #warning (C/C++ preprocessor extension)

Nicolas Goutte nicolasg at snafu.de
Tue Nov 1 16:33:31 GMT 2005


On Tuesday 01 November 2005 17:15, Martijn Klingens wrote:
> On Tuesday 01 November 2005 16:57, Nicolas Goutte wrote:
> > On Tuesday 01 November 2005 13:26, Martijn Klingens wrote:
> > > Doesn't it work if you patch the failing Qt includes with '#pragma GCC
> > > system_header'? AFAICS that shouldn't affect BC and should suppress the
> > > warnings and hence the -Werror traps.
> >
> > That is the kind of things I meant. You have to add a gcc-ism to keep the
> > compiler calm. But we are supposed to make *portable* code!
>
> C'mon, don't cry wolf.
>
> -Werror is a gcc-ism too. 

Perhaps the exact name of the flag, but not the function.

In an old C compiler, it could have a sence even, as lint was a separate 
program.

It can have a sence in compiler like MSVC which can control easily the 
importance level of warnings. (That is the only thing that I miss from that 
compiler in GCC.) So when you want to check seriously, you can force warnings 
of "maximal level 2" (of 4 levels) and force the "warning-is-error" function.
And in normal development, you use all 4 warning levels without forcing them 
as errors.

(Again, disclaimer: I used MSVC years ago, so it could be well, that this 
compiler has changed much in the meantime.)

(...)

> > I do not think that extra #ifs are better than warnings. (I would even
> > think the contrary, as it makes the code less readable.)
>
> Please read the thread more carefully -- this part was about turning
> warnings into errors, and was talking about ALL warnings, including those
> that the compiler generates itself. It was a sidestep from the #warning
> discussion and has little to do with it anymore.

Yes, but it was also about not using warnings to remind that something has to 
be done in code. So if you want a clear compiler warning, instead of just a 
reminder for the developer who has done it, it means using #warning.

Have a nice day!





More information about the kde-core-devel mailing list