RFC: When to use #warning ?

[Friedrich W. H. Kossebau]

Hi Jarosław,

Am Montag, 28. Januar 2013, 22:36:57 schrieb Jaroslaw Staniek:
> Hello Friedrich,
> I generally agree what you say here and will look step by step, which
> would take 'some time'. I hope someone would help so below I explain
> how.

Good. At least I am tempted to continue my warning hunting also on Kexi ground 
:)

> Nearly no new #warnings were added after Kexi started to compile with
> Qt 4. Any new code conforms to the guidelines and older is cleaned up
> occasionally. As I said on IRC, these warnings are either related to
> serious porting issues or come from the use of deprecated/qt3support
> code.

Missed that on IRC, but learn it now :)

> Example: #warning "Port this.."
> Fixing each porting issue is nontrivial (coding, testing).  If you see
> warning in deprecated/qt3support code in headers, these are insanely
> multiplied if the header is included in many places.

it's basically these warning where I wonder if they should not better be done 
as @todo, instead of popping up during the build as well. The problem is 
already known and noted down in the code, no real need to have the compiler 
spit that warning out as well, or?

> Just fixed one in
> KexiView.h...

:)

> Anyone, feel free to propose fixes for deprecated QPalette use for
> example, it's doable.

Sure, hopefully coming up with a patch for that as well. But these are 
warnings that the compilers finds out and tells about because asked to by the 
responding -W flag, right? Nothing manually added to the code.

> Similar case applies to 'hiding methods by
> overloads' warning.

To your command: patch against "hiding methods" already up and waiting here: 
https://git.reviewboard.kde.org/r/108588/ :)

> 47 warnings come from kexi/migration/mdb/src/mdbtools/libmdb and these
> won't be fixed since this is 3rd-party code that I prefer not to patch
> just for this reason. Please note that fixing glib-based C code may
> even introduce regressions.

Sure. So far skipped any imported/forked/3rdparty-marked libs. Possibly we 
might move them all to 3rdparty/, so we have better overview? Will start talk 
about that some other time, not now :)

> Again, thanks for the detailed note.
> 
> > Most commits
> > were some simple fixes like removing/hiding unused parameters/variables,
> > so I felt free to skip any review process and to simply commit directly,
> > noone might have had fun reviewing them anyway ;) Managed to cut around 6
> > % of the warnings (/me pats himself on the back),
> 
> Good job, big thanks!

Thanks, happy to also read that and not just hope for :)

> > Advantages that I see:
> > * can be done with different keywords, to map to different kind of TODOs
> > * quickly collectable without a compiler/build run, using grep & Co.
> > * does not clutter the warnings which only the compiler can find out about
> 
> I am advertising //! @todo Foo
> 
> (and we've been using this for a long time)

Okay, was not obvious from my primitive grepping, pardon me. Happy to read 
that I am just following where you are going already :)

Cheers
Friedrich