RFC: Avoiding #warning (C/C++ preprocessor extension)
js at iidea.pl
Sun Oct 30 23:13:27 GMT 2005
Olivier Goffart said the following, On 2005-10-31 00:16:
> Le Dimanche 30 Octobre 2005 21:25, Jarosław Staniek a écrit :
>>Since KDE is becoming more portable, my proposal is to avoid using #warning
>>C/C++ preprocessor's extension. Unlike #error, #warning is not a standard -
>>several compilers in addition to gcc implement this. Msvc compiler does
> All of this is correct.
> Anyway, #warning are just temporary code, and they should be removed before
> the release.
> A good code compiles without warnings at all.
> We should not simply remove the #warning line, but also fix the code.
Yes, so I asked about a way to replace #warning with something similar but
allowing the code to compile.
>>To find a solution I would propose to:
>>1. Preferred way: Using doxygen @todo tag instead of #warning. Then
>>warnings can be accessible:
>>1.1. Within Doxygen docs (Related Pages->Todo list), eg.
>>cs/kdecore/html/todo.html 1.2. By just grepping for @todo. This is no
>>different to using #warnings because every #warning can quickly disappear
>>from your screen during compilation, so you still need to find it in the
> This is a bit different: @todo are placed in header, and not directly in the
> code they show.
Could there be a problem with placing them directly in the code? We're already
using doxygen in the code, in particular, @internal
> also #warning are generally used for more important things, while @todo may be
> long terms.
> There is also a flag to make all warnings act like fatal error, to force to
> fix them.
So what about @warning ?
Eventually, if Doxygen substitutes are not enough, we could stay with:
Not a problem for me, as in kdelibs3. And #warnings will disappear when code
regards / pozdrawiam,
Jaroslaw Staniek / OpenOffice Polska
http://www.kexi-project.org | http://koffice.org/kexi
KDE3, KDE4 libraries for developing MS Windows applications:
More information about the kde-core-devel