RFC: Avoiding #warning (C/C++ preprocessor extension)
Nicolas Goutte
nicolasg at snafu.de
Mon Oct 31 20:26:22 GMT 2005
On Monday 31 October 2005 00:13, Jaroslaw Staniek wrote:
> 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 not.
> >
> > 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.
> >>http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-api
> >>do 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 code.
> >
> > 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
If it has not changed in the meantime, only headers are parsed for the on-line
Doxygen documentation.
If it is not there as @todo, it is not much of an alternative.
>
> > 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:
>
> #ifdef __GNU__
> #warning foo
> #endif
>
> Not a problem for me, as in kdelibs3. And #warnings will disappear when
> code stablilizes.
No, at least the one of KCharsets will remain, as the code will never be
modified. (What good to modify it now that KDE 3 is nearly finished.)
More information about the kde-core-devel
mailing list