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

[alexander golks]

hi,

i wonder why you just don't store QObject* in the lists?
moving from objects to pointers should be "just" fleißarbeit ;)

alex

Am Mon, 20 Jul 2015 22:18:50 +0200
schrieb "Jason H" <jhihn at gmx.com>:

> And the problem with PHP is that it works at all. ;-)
> 
> Wouldn't the modifications you inquire make a mess of the implicit data sharing?
> 
> 
> > Sent: Monday, July 20, 2015 at 1:02 PM
> > From: "Gunnar Roth" <gunnar.roth at gmx.de>
> > To: "Guido Seifert" <wargand at gmx.de>
> > Cc: interest at qt-project.org
> > Subject: Re: [Interest] Need argumentative help..... giving qobject copy/assignment constructor and put it in qlist/qmap
> >
> > Hi Guido,
> > i know quite a many bad c/c++ code that worked … for a while ;-) thats the problem with many bad c/c++ code, that it works somehow.
> > > Am 20.07.2015 um 18:53 schrieb Guido Seifert <wargand at gmx.de>:
> > > 
> > > 
> > > One should think this is a clear warning sign. :-)
> > > But the code worked. So problem solved. Now I am wondering if I was over-cautious, or if there are less obvious problems. With different compilers? Platforms? Some less known QMap/QList features, which might shuffle the objects around? Not that the obvious stuff isn't enough NOT to do this. 
> > > 
> > > On Mon, 20 Jul 2015 18:41:16 +0200
> > > Gunnar Roth <gunnar.roth at gmx.de> wrote:
> > > 
> > >> Hi,
> > >> well i think thats even worse. You have to call the base class copy constructor in any derived copy constructor but you cannot as it is private ( and even not implemented),
> > >> so that was not enough warning for them not to do this?
> > >> 
> > >> 
> > >>> Am 20.07.2015 um 18:38 schrieb Guido Seifert <wargand at gmx.de>:
> > >>> 
> > >>> No, they gave a class, which inherits QObject a copy/assignment constructor. Not as bad as patching Qt, but still not a good idea.
> > >>> 
> > >>> On Mon, 20 Jul 2015 18:35:08 +0200
> > >>> Gunnar Roth <gunnar.roth at gmx.de> wrote:
> > >>> 
> > >>>> Hi Guido,
> > >>>> you mean they have patched qt and gave Object an assignment operator and copy constructor?
> > >>>> Really?
> > >>>> 
> > >>>> Regards,
> > >>>> Gunnar
> > >>>> 
> > >>>> 
> > >>>>> Am 20.07.2015 um 14:51 schrieb Guido Seifert <wargand at gmx.de>:
> > >>>>> 
> > >>>>> 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 ;-)
> > >>>>> -- 
> > >>>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> > >>>>> _______________________________________________
> > >>>>> Interest mailing list
> > >>>>> Interest at qt-project.org
> > >>>>> http://lists.qt-project.org/mailman/listinfo/interest
> > >>>> 
> > >> 
> > > _______________________________________________
> > > Interest mailing list
> > > Interest at qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/interest
> > 
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 
/*
 *  The smallest worm will turn being trodden on.
 *      -- William Shakespeare, "Henry VI"
 */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150721/f2e2206a/attachment.sig>