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
