RFC: When to use #warning ?

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

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.

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. Just fixed one in
KexiView.h...

Anyone, feel free to propose fixes for deprecated QPalette use for
example, it's doable. Similar case applies to 'hiding methods by
overloads' warning.

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.

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!

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

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek