[Development] Compiler warnings

[Kurt Pattyn]

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: http://en.m.wikipedia.org/wiki/Cluster_(spacecraft)
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.

Cheers,

Kurt

> 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 keep
>> binary compatibility, you break semantics here. This is typically a case
>> 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 instead.
> 
> void QWidget::repaint ( int x, int y, int w, int h, bool b )
> The boolean parameter b is ignored. Use the four-argument overload instead.
> 
> void QWidget::repaint ( const QRect & r, bool b )
> The boolean parameter b is ignored. Use the single rect-argument overload 
> instead.
> 
> void QWidget::repaint ( const QRegion & rgn, bool b )
> The boolean parameter b is ignored. Use the single region-argument overload 
> instead.
> 
> void QWidget::setBackgroundMode ( Qt::BackgroundMode widgetBackground, 
> Qt::BackgroundMode paletteBackground = Qt::PaletteBackground )
> Sets the color role used for painting the widget's background to background 
> mode widgetBackground. The paletteBackground mode parameter is ignored.
> 
> 
> I also remember having encountered other functions where parameters were 
> documented as no longer used, and even functions documented as having no 
> effect anymore, but those were probably in KDE libraries, not in Qt itself.
> 
>        Kevin Kofler
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development