Re: [Development] Compiler warnings
On Oct 17, 2014, at 7:26 PM, Mathias Hasselmann math...@taschenorakel.de
wrote:
Am 17.10.2014 um 18:31 schrieb Thiago Macieira:
On Friday 17 October 2014 13:06:39 Milian Wolff wrote:
enum Foo {
Bar = 1, Baz = 2
};
Foo foo = static_castFoo(3);
Now what do you do without a default clause?
Shoot the developer who abused the API.
If the function accepts enum values 1 and 2 and you pass a 3, you deserve the
undefined behaviour.
That is the same as passing a bool that doesn't contain exactly values 0 or 1
or passing an uninitialised pointer.
We have to handle all regular conditions. We don't have to guard against
stupidity.
I don't think this example has to do with stupidity. To me this just
seems like a minimal example of typical integration problems that happen
in real world.
If you need to convert between integers and enum values (or one enum and
another), and you care about safety of your application (i.e. always), do
explicit conversion with an if on the integer (switch on that other enum), and
do the error handling at the place where the conversion happens.
Far fetching I'd talk about distributed services, reading
files written by a different program version, and such. Also Qt already
deals with such issues where it is obvious:
const char * QVariant::typeToName(int typeId) [static]
Converts the int representation of the storage type, typeId, to its
string representation.
Returns a null pointer if the type is QVariant::Invalid(obsolete)
or doesn't exist.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
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.kof...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
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. Cheers, Lars On 17/10/14 08:48, Kurt Pattyn pattyn.k...@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: 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.kof...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 10/17/2014 08:48 AM, Kurt Pattyn wrote: 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) Doesn't this actually make the code *worse* when using enums? Adding a default statement when you handle all possible values will inhibit genuine compiler warnings when you forget to add a case for a newly added enum value. In fact, this is almost guaranteed to happen in a non-trivial project, so this rule seems almost absurdly wrong to me. Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 17 Oct 2014, at 10:15, Christian Kandeler christian.kande...@digia.com wrote: On 10/17/2014 08:48 AM, Kurt Pattyn wrote: 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) Doesn't this actually make the code *worse* when using enums? Adding a default statement when you handle all possible values will inhibit genuine compiler warnings when you forget to add a case for a newly added enum value. In fact, this is almost guaranteed to happen in a non-trivial project, so this rule seems almost absurdly wrong to me. Regulations are usually not an example of common sense :-) Maybe version 2020-TR/A-99576-37A-ammendment37bis will remove this :-) Sigggh Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 17/10/2014 10:15, Christian Kandeler wrote: On 10/17/2014 08:48 AM, Kurt Pattyn wrote: 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) Doesn't this actually make the code *worse* when using enums? Adding a default statement when you handle all possible values will inhibit genuine compiler warnings when you forget to add a case for a newly added enum value. In fact, this is almost guaranteed to happen in a non-trivial project, so this rule seems almost absurdly wrong to me. That one is always subject to debate. There is one thing not to forget in favor of this rule : enums are *not* guaranted to have a value amongst the defined ones. Undefined behaviour in that case is not an option. I wish i could have both a default statement and my compiler warning… Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Den 17-10-2014 12:22, Julien Blanc skrev:
On 17/10/2014 10:15, Christian Kandeler wrote:
On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
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)
Doesn't this actually make the code *worse* when using enums? Adding a
default statement when you handle all possible values will inhibit
genuine compiler warnings when you forget to add a case for a newly
added enum value. In fact, this is almost guaranteed to happen in a
non-trivial project, so this rule seems almost absurdly wrong to me.
That one is always subject to debate. There is one thing not to forget
in favor of this rule : enums are *not* guaranted to have a value
amongst the defined ones. Undefined behaviour in that case is not an option.
I wish i could have both a default statement and my compiler warning…
switch (enumValue) {
case E1: ...; break;
case E2: ...; break;
case Nope1:
case Nope2:
// Intentionally not handled
break;
}
Boom. Can I invoice you for this now? :)
Bo.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 17/10/2014 11:44, Bo Thorsen wrote:
Den 17-10-2014 12:22, Julien Blanc skrev:
On 17/10/2014 10:15, Christian Kandeler wrote:
On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
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)
Doesn't this actually make the code *worse* when using enums? Adding a
default statement when you handle all possible values will inhibit
genuine compiler warnings when you forget to add a case for a newly
added enum value. In fact, this is almost guaranteed to happen in a
non-trivial project, so this rule seems almost absurdly wrong to me.
That one is always subject to debate. There is one thing not to forget
in favor of this rule : enums are *not* guaranted to have a value
amongst the defined ones. Undefined behaviour in that case is not an option.
I wish i could have both a default statement and my compiler warning…
switch (enumValue) {
case E1: ...; break;
case E2: ...; break;
case Nope1:
case Nope2:
// Intentionally not handled
break;
}
Boom. Can I invoice you for this now? :)
See also, Q_UNREACHABLE().
Cheers,
Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Friday 17 October 2014 12:44:09 Bo Thorsen wrote:
Den 17-10-2014 12:22, Julien Blanc skrev:
On 17/10/2014 10:15, Christian Kandeler wrote:
On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
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)
Doesn't this actually make the code *worse* when using enums? Adding a
default statement when you handle all possible values will inhibit
genuine compiler warnings when you forget to add a case for a newly
added enum value. In fact, this is almost guaranteed to happen in a
non-trivial project, so this rule seems almost absurdly wrong to me.
That one is always subject to debate. There is one thing not to forget
in favor of this rule : enums are *not* guaranted to have a value
amongst the defined ones. Undefined behaviour in that case is not an
option.
I wish i could have both a default statement and my compiler warning…
switch (enumValue) {
case E1: ...; break;
case E2: ...; break;
case Nope1:
case Nope2:
// Intentionally not handled
break;
}
Boom. Can I invoice you for this now? :)
I think you are missing something:
enum Foo {
Bar = 1, Baz = 2
};
Foo foo = static_castFoo(3);
Now what do you do without a default clause?
Bye
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 10/17/2014 01:06 PM, Milian Wolff wrote:
I think you are missing something:
enum Foo {
Bar = 1, Baz = 2
};
Foo foo = static_castFoo(3);
If you start to guard against this kind of stuff, where does it end?
void f(void *p);
f(reinterpret_castvoid *(5));
Is f supposed to catch that?
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 17 Oct 2014, at 12:54, Sean Harmer sean.har...@kdab.com wrote:
On 17/10/2014 11:44, Bo Thorsen wrote:
Den 17-10-2014 12:22, Julien Blanc skrev:
On 17/10/2014 10:15, Christian Kandeler wrote:
On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
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)
Doesn't this actually make the code *worse* when using enums? Adding a
default statement when you handle all possible values will inhibit
genuine compiler warnings when you forget to add a case for a newly
added enum value. In fact, this is almost guaranteed to happen in a
non-trivial project, so this rule seems almost absurdly wrong to me.
That one is always subject to debate. There is one thing not to forget
in favor of this rule : enums are *not* guaranted to have a value
amongst the defined ones. Undefined behaviour in that case is not an option.
I wish i could have both a default statement and my compiler warning…
switch (enumValue) {
case E1: ...; break;
case E2: ...; break;
case Nope1:
case Nope2:
// Intentionally not handled
break;
}
Boom. Can I invoice you for this now? :)
See also, Q_UNREACHABLE().
Indeed, but the main reason that all cases must be handled is to avoid
arbitrary crashes of an application.
And handling does not mean just adding comments. We cannot afford that an X-Ray
scanner crashes while beaming its X-rays onto a patient.
We cannot afford that a Boeing goes down because the software just crashes.
We speak of life critical applications here; in all other cases, most of these
measures are merely overkill.
Q_UNREACHABLE() is fine if we can *prove* that indeed it will never be reached;
the latter being nearly impossible.
Cheers,
Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Christian,
the problem is often when your software has to be integrated into other
software and systems, which is almost always the case in life-critical systems.
If your software is controlling a critical component like an X-ray beamer for
instance, you’d better be prepared for all kinds of rubbish that can enter your
software.
The same holds for cockpit displays for instance; they need to take in a lot of
external signals, and that can go wrong.
It is more like ‘Be prepared for the worst and nothing will happen’.
Cheers,
Kurt
On 17 Oct 2014, at 13:10, Christian Kandeler christian.kande...@digia.com
wrote:
On 10/17/2014 01:06 PM, Milian Wolff wrote:
I think you are missing something:
enum Foo {
Bar = 1, Baz = 2
};
Foo foo = static_castFoo(3);
If you start to guard against this kind of stuff, where does it end?
void f(void *p);
f(reinterpret_castvoid *(5));
Is f supposed to catch that?
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Wednesday 15 October 2014 10:59:41 Bo Thorsen wrote: Oh, come on. It's just one example of one bad rule. And even if you don't accept my example for it, I can just give you another. I have a base class that declares an interface for subclasses. One method requires that the subclass looks at one of the input files and determines the date. To do this, the method declaration has three different arguments, and each of the subclass will use anything from one to three of those. When a subclass doesn't use one of the arguments, it breaks the rule. Which is why the rules you pasted mention clearly non-virtual functions. And for all the other cases, we have Q_UNUSED for a reason. Obviously a rule written by C programmers that thought they could just apply their knowledge to C++. I will stand by my initial statement: MISRA is irrelevant for a framework. Whether you might use it in your application is up to you. But even here, I can see you break this example. I won't respond again to this thread, it's already too far off topic. Bo. Den 15-10-2014 kl. 10:52 skrev Kurt Pattyn: On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote: Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. 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. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Yes, if the semantics of the method changes. I can hardly imagine that obsoleting a parameter from a method does not have any behavioural impact in the calling application. This even holds for the case when the signature of the method does not change at all, but the semantics do. I remember once having replaced strict floating point compares with qFuzzyCompares. Although this was internal to Qt this change was - correctly - rejected. Cheers, Kurt Andre' Bo Thorsen, Director, Viking Software. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Am 17.10.2014 um 13:16 schrieb Kurt Pattyn:
On 17 Oct 2014, at 12:54, Sean Harmer sean.har...@kdab.com wrote:
On 17/10/2014 11:44, Bo Thorsen wrote:
Den 17-10-2014 12:22, Julien Blanc skrev:
On 17/10/2014 10:15, Christian Kandeler wrote:
On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
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)
Doesn't this actually make the code *worse* when using enums? Adding a
default statement when you handle all possible values will inhibit
genuine compiler warnings when you forget to add a case for a newly
added enum value. In fact, this is almost guaranteed to happen in a
non-trivial project, so this rule seems almost absurdly wrong to me.
That one is always subject to debate. There is one thing not to forget
in favor of this rule : enums are *not* guaranted to have a value
amongst the defined ones. Undefined behaviour in that case is not an
option.
I wish i could have both a default statement and my compiler warning…
switch (enumValue) {
case E1: ...; break;
case E2: ...; break;
case Nope1:
case Nope2:
// Intentionally not handled
break;
}
Boom. Can I invoice you for this now? :)
See also, Q_UNREACHABLE().
Indeed, but the main reason that all cases must be handled is to avoid
arbitrary crashes of an application.
And handling does not mean just adding comments. We cannot afford that an
X-Ray scanner crashes while beaming its X-rays onto a patient.
We cannot afford that a Boeing goes down because the software just crashes.
We speak of life critical applications here; in all other cases, most of
these measures are merely overkill.
Q_UNREACHABLE() is fine if we can *prove* that indeed it will never be
reached; the latter being nearly impossible.
It's not only life critical systems. It's already if you want your
software to appear as high quality, that do graceful error recovery.
Anyway, my default pattern to get compiler warnings while also handling
unexpected values:
auto supportFunction(Enum value)
{
switch (value) {
case Foo:
handleFoo();
return ...;
case Bar:
handleBar();
return ...;
}
logErrorCondition();
runGracefulFallbackAction();
}
The major trick is to use return instead of break. Brave people might
use a goto instead of that return and that support function, I don't.
Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Friday 17 October 2014 19:26:56 Mathias Hasselmann wrote: Shoot the developer who abused the API. If the function accepts enum values 1 and 2 and you pass a 3, you deserve the undefined behaviour. That is the same as passing a bool that doesn't contain exactly values 0 or 1 or passing an uninitialised pointer. We have to handle all regular conditions. We don't have to guard against stupidity. I don't think this example has to do with stupidity. To me this just seems like a minimal example of typical integration problems that happen in real world. Far fetching I'd talk about distributed services, reading files written by a different program version, and such. Also Qt already deals with such issues where it is obvious: const char * QVariant::typeToName(int typeId) [static] Converts the int representation of the storage type, typeId, to its string representation. That's not a good example. My point is that an API that is documented to have only values 1 and 2 should not have to handle value 3. That is not the case of dealing with metatypes. That's why in most cases we actually use ints, as shown above, than the enums from QVariant and QMetaType. If you abuse an API, you deserve crashes. I will not support changes to Qt that try to deal with stupidities. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Smith Martin wrote: But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. The lack of a name for the parameter is already how the C++ standard specifies unused parameters, and g++ normally does NOT warn in that case. In addition, GCC/g++ has supported __attribute__((unused)) for ages. For Qt code, there's also the Q_UNUSED macro, which is used in the function itself, and which should work with most (if not all) compilers out there. But all those should not be needed in cases where you can simply omit the parameter name. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
But if lack of a parameter name means unused (by choice) parameter, then compilers shouldn't warn that it is an unused parameter. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Kevin Kofler kevin.kof...@chello.at Sent: Thursday, October 16, 2014 7:46 PM To: development@qt-project.org Subject: Re: [Development] Compiler warnings Smith Martin wrote: But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. The lack of a name for the parameter is already how the C++ standard specifies unused parameters, and g++ normally does NOT warn in that case. In addition, GCC/g++ has supported __attribute__((unused)) for ages. For Qt code, there's also the Q_UNUSED macro, which is used in the function itself, and which should work with most (if not all) compilers out there. But all those should not be needed in cases where you can simply omit the parameter name. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. 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. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Poenitz Andre andre.poen...@theqtcompany.com Sent: Wednesday, October 15, 2014 9:48 AM To: Kurt Pattyn; Bo Thorsen Cc: development@qt-project.org Subject: Re: [Development] Compiler warnings Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. 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. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. martin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Wed, 15 Oct 2014, Smith Martin wrote: But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. ... and emit an error if it is :) Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote: Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. 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. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Yes, if the semantics of the method changes. I can hardly imagine that obsoleting a parameter from a method does not have any behavioural impact in the calling application. This even holds for the case when the signature of the method does not change at all, but the semantics do. I remember once having replaced strict floating point compares with qFuzzyCompares. Although this was internal to Qt this change was - correctly - rejected. Cheers, Kurt Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Oh, come on. It's just one example of one bad rule. And even if you don't accept my example for it, I can just give you another. I have a base class that declares an interface for subclasses. One method requires that the subclass looks at one of the input files and determines the date. To do this, the method declaration has three different arguments, and each of the subclass will use anything from one to three of those. When a subclass doesn't use one of the arguments, it breaks the rule. Obviously a rule written by C programmers that thought they could just apply their knowledge to C++. I will stand by my initial statement: MISRA is irrelevant for a framework. Whether you might use it in your application is up to you. But even here, I can see you break this example. I won't respond again to this thread, it's already too far off topic. Bo. Den 15-10-2014 kl. 10:52 skrev Kurt Pattyn: On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote: Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. 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. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Yes, if the semantics of the method changes. I can hardly imagine that obsoleting a parameter from a method does not have any behavioural impact in the calling application. This even holds for the case when the signature of the method does not change at all, but the semantics do. I remember once having replaced strict floating point compares with qFuzzyCompares. Although this was internal to Qt this change was - correctly - rejected. Cheers, Kurt Andre' Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Wednesday 15 October 2014 09:26:34 Kurt Pattyn wrote: I am talking about missing default switch statements, incomplete switch statements, implicit conversion between signed and unsigned integers, aso. default labels in switches may be intentionally missing. When the swtch handles all possible values, it's unnecessary to add a default. Especially when the switch handles all possible values of an enum, you don't want a default label so you'll get a warning later when a new enum value may be added. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Compiler warnings
Hi, This has already been brought up before: when compiling an application/library using Qt and setting compiler warnings to comply with e.g. the Misra C++ rules, Qt generates a lot of warnings. I already did some work on eliminating some of the warnings, but there are still quite a lot left. A number of these changes never got through, having forced me to locally patch Qt to avoid them. Now my questions: 1. Is it worth the (big) effort to try to remove these warnings from the public part of Qt? 2. Are there other people, esp. working in strongly regulated environments that have the same problem? I see that Qt is used a lot in the automotive industry: how do these applications comply with MISRA? Cheers, Kurt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Tuesday 14 October 2014 08:59:27 Kurt Pattyn wrote: 1. Is it worth the (big) effort to try to remove these warnings from the public part of Qt? Again, it depends on how intrusive those patches are. We already build Qt with a compiler warning check for all public headers and we could add a few more options to the compiler flags to enable more warnings. Not all of those that you wanted. That just made the code ugly. 2. Are there other people, esp. working in strongly regulated environments that have the same problem? I see that Qt is used a lot in the automotive industry: how do these applications comply with MISRA? They don't. MISRA doesn't apply to the IVI system. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. There are also cases where base classes get info to methods that subclasses do not need. Sure, I can do something that could fool an automatic code checker, but that doesn't mean the rule is not violated. This is just one example. MISRA is something you use for your own code, if you feel the need to hurt or punish yourself. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
