Den 14-10-2014 08:59, Kurt Pattyn skrev:
> 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 th
On Oct 17, 2014, at 7:26 PM, Mathias Hasselmann
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_cast(3);
>>>
>>> Now what do you do without a default cl
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
> On 17 Oct 2014, at 19:26, Mathias Hasselmann 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_cast(3);
>>>
>>> Now what do you do without a defau
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_cast(3);
>>
>> Now what do you do without a default clause?
>
> Shoot the developer who abused the API.
>
> If the function accep
On Friday 17 October 2014 13:06:39 Milian Wolff wrote:
> enum Foo {
> Bar = 1, Baz = 2
> };
>
> Foo foo = static_cast(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
undef
Am 17.10.2014 um 13:16 schrieb Kurt Pattyn:
>
>> On 17 Oct 2014, at 12:54, Sean Harmer 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
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 lo
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 rub
> On 17 Oct 2014, at 12:54, Sean Harmer 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 an
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_cast(3);
If you start to guard against this kind of stuff, where does it end?
void f(void *p);
f(reinterpret_cast(5));
Is f supposed to catch that?
Chri
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
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 wit
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
>>>
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
> On 17 Oct 2014, at 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 (irrespectiv
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, ridicul
On 17 Oct 2014, at 09:18, Knoll Lars wrote:
> 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 heade
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
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. Th
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
rsday, 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 cou
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 d
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 pos
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 th
On 15 Oct 2014, at 09:48, Poenitz Andre wrote:
> Kurt Pattyn wrote:
>>> On 14 Oct 2014, at 10:21, Bo Thorsen 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,
>>>
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, co
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Poenitz Andre
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 wrote:
> > On 14 Oct 2014, at
Kurt Pattyn wrote:
> > On 14 Oct 2014, at 10:21, Bo Thorsen 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 n
Hi Bo,
> On 14 Oct 2014, at 10:21, Bo Thorsen 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 (na
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 /*
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
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
33 matches
Mail list logo
