[Development] Compiler warnings

[Bo Thorsen]

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.Poenitz at theqtcompany.com> wrote:
>
>> 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.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu