[Development] Compiler warnings
olivier at woboq.com
Fri Oct 17 13:52:31 CEST 2014
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.
> Den 15-10-2014 kl. 10:52 skrev Kurt Pattyn:
> > On 15 Oct 2014, at 09:48, Poenitz Andre <Andre.Poenitz at theqtcompany.com>
> >> Kurt Pattyn <pattyn.kurt at gmail.com> wrote:
> >>>> On 14 Oct 2014, at 10:21, Bo Thorsen <bo at 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.
More information about the Development