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