> 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 :)
Oh, I had plenty of arguments, but at first it looked like they were not enough. Basically the same arguments Rainer Wiesenfart mentioned at the beginning of the thread: >> What about: >> - the QObject's parent? Is it set with setParent(other->parent()) or set to >> nullptr? nullptr. So... parent not a problem. >> - the QObject's thread? Is it guaranteed that it is the same thread that >> creates the copy? Yes >> - the QObject's children? Who is going to own them and when are they deleted? Does not have any. >> - the QObject's connections? Will all copies emit the same signals, will all >> copies have their slots called? Worked somehow... probably through magic. This was my problem. It really looked like we could get away with it. The whole class did not really need to be a QObject. It was only a QObject because it was used from QML. The whole design was questionable. > 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. It did work. But of course we had a broken object. And as I said, it was used together with QML. While I have a fairly good grasp on what happens in memory in pure C++ classes, I the inner workings of QML/C++ interface is a bit of magic to me. > 3) They need a patched Qt for all future. Nope, they did not patch Qt. Just gave a QObject subclass a copy- and assignment-constructor. > 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. Yep, a disaster in waiting. I discovered it when VS 2013 choked on it. VS 2005 did not see a problem. IMHO it was a very brittle solution. > 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. I would not go that far. The developer did not know that QObject cannot be copied... even though the private constructors should be a dead giveaway. He admitted the code was a hack... but never got the time to clean it up. Not a totally unheard story. Part of the blame should go to management. When I gave him above arguments, he just tried to stall... Understandable considering the somewhat tight time frame we have. When he wanted that I do something similar somewhere else, I kind of panicked... and asked here for more input. Having to live with such code is one thing, but being forced to write it myself... *shiver*. Fortunately he is not a bad developer. Turned out I did not have to ask here, when I gave him the part of the QObject docu, especially the Q_DISABLE_COPY(Class) part, he finally accepted the bad news. I got the permission to rewrite the classes.... they are still no master piece, but acceptable now. Guido > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
