[Interest] Need argumentative help..... giving qobject copy/assignment constructor and put it in qlist/qmap

[Bo Thorsen]

Den 20-07-2015 kl. 14:51 skrev Guido Seifert:
> Hi, just seen this in project's code. Worse, I have been told to do it
> exactly this way in another code part. I must say I am less than
> thrilled. On first glance this code seems to work. There is not much
> copying around. The objects sit happily in their containers. But it
> smells. So what is the worst what can be expected? Something not
> obvious? On different compilers? I need some convincing reasons, which
> cannot just waved away..... or confirmation that eveything is fine and I
> can stop worrying.... but this also must be convincing. Perhaps even
> more ;-)

The problem with this kind of bad hack that people judge it on whether 
or not they could get away with it. "It compiles? Ship it!"

I think your problem is that your spidey sense is ringing so hard that 
you lost the ability to give arguments about this :)

The problem you have is that it can actually work, as long as they don't 
use the memory management of QObject. So if the counter argument is "we 
won't do that", (which is probably the case) and this argument is 
accepted by the management, then you have a problem. Or rather, your 
customer has a problem that goes deeper than the current piece of code.

In addition to the technical arguments that you already got on 
parent-child ownership, signal-slot connections and threats, there are a 
couple more here:

1) Every subclass of QObject assumes it can't be copied. Unless they 
went into every direct subclass and explicitly disabled copying, that is 
now allowed for all of them. Both for all Qt subclasses and QObject 
subclasses in their own code. Good luck catching the crashes from this.

2) When someone introduces code that relies on other developers to not 
use a set of features or it breaks, that is a perfect recipe for 
maintenance hell.

3) They need a patched Qt for all future. Ask their manager to calculate 
the cost of this. Even if they currently have other Qt patches, that 
doesn't mean they will in the future, because it's impossible that this 
change will ever be accepted in Qt itself. This also means shipping the 
patched Qt sources if they use one of the OSS licenses.

4) Even though it might accidentally work right now, there's obviously 
no guarantee that it will in the future. So they might end up stuck with 
a Qt version unless they fix their code anyway.

I would also identify the people who did this change, because I would 
not trust any judgement on their side, so any code change from them is 
considered suspect. This is such a horrible idea that it shows a 
fundamentally flawed ability to make design choices.

Bo Thorsen,
Director, Viking Software.

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