[Development] Compiler warnings

Knoll Lars Lars.Knoll at theqtcompany.com
Fri Oct 17 09:18:28 CEST 2014

It has always been our goal to keep the public headers as clean as
possible. So removing a few more cases where they can cause warnings is in
principle a good goal. The main place to be careful is (as Thiago said),
if the changes make the headers significantly less readable. I’d also like
to avoid changes that break our coding style.


On 17/10/14 08:48, "Kurt Pattyn" <pattyn.kurt at gmail.com> wrote:

>Leaving out the parameter name is not a problem. A better approach is
>marking the parameter as unused. But, the potential problem lays in
>breaking semantic compatibility.
>A very nice example is:
>Interfaces were compatible, semantics were not. That's why I said before
>that in such a case binary compatibility must be broken. That's also why
>Lars once rejected a patch of mine where I replaced float comparisons
>with qFuzzyCompare.
>As we are developing for aerospace, avionics, defence and healthcare, we
>are confronted on a daily basis with a lot of very stringent rules that
>we have to comply with (irrespective if some people might find these
>rules outdated, stupid, ridiculous or not). That's why we always compile
>with as much compiler warnings as possible. Our code must be audited by
>an external office anyways, so we better make sure we can avoid a bad
>report as soon as possible.
>Some examples of 'stupid' rules (which after second consideration aren't
>that stupid after all):
>- a switch statement must always have a default statement (also all cases
>must be handled)
>- always use curly braces with blocks (if, for,while, ... statements),
>even if it is only one line.
>- never interchangeably use signed and unsigned variables
>- never leave commented out code in the source
>- ...
>Because we use Qt in a lot of our software (not aerospace and avionics
>where Ada is king), it is in our interest to have warnings of the public
>API be reduced to a minimum.
>Nothing more, nothing less.
>I want to contribute patches, but if people find it nitpicking and not
>worth the effort, then it is useless to spend my precious time on it.
>> On 16 Oct 2014, at 21:04, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Kurt Pattyn wrote:
>>> On second thought, I think this is a very bad example. Even while you
>>> binary compatibility, you break semantics here. This is typically a
>>> where one should break binary compatibility.
>>> I am sure (or at least I hope so) that Qt does not allow these kind of
>>> things.
>> Qt also tries to maintain partial source compatibility with previous
>> versions, so, e.g., Qt 4 has these Qt3Support members of QWidget:
>> void QWidget::repaint ( bool b )
>> The boolean parameter b is ignored. Use the no-argument overload
>> void QWidget::repaint ( int x, int y, int w, int h, bool b )
>> The boolean parameter b is ignored. Use the four-argument overload
>> void QWidget::repaint ( const QRect & r, bool b )
>> The boolean parameter b is ignored. Use the single rect-argument
>> instead.
>> void QWidget::repaint ( const QRegion & rgn, bool b )
>> The boolean parameter b is ignored. Use the single region-argument
>> instead.
>> void QWidget::setBackgroundMode ( Qt::BackgroundMode widgetBackground,
>> Qt::BackgroundMode paletteBackground = Qt::PaletteBackground )
>> Sets the color role used for painting the widget's background to
>> mode widgetBackground. The paletteBackground mode parameter is ignored.
>> I also remember having encountered other functions where parameters
>> documented as no longer used, and even functions documented as having
>> effect anymore, but those were probably in KDE libraries, not in Qt
>>        Kevin Kofler
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>Development mailing list
>Development at qt-project.org

More information about the Development mailing list