On segunda-feira, 14 de maio de 2012 13.16.46, Olivier Goffart wrote: > On Monday 14 May 2012 11:42:33 Thiago Macieira wrote: > > On segunda-feira, 14 de maio de 2012 11.36.04, Thiago Macieira wrote: > > > Since no one has a suggestion on how to fix the hack, I'll close the > > > task > > > and abandon the patch that cleans up QEvent. > > I think you should keep the change, just remove the assert.
I can't do that. It would mean that the d pointer could be overwriting
something.
Besides, it's not the assertion in qgraphicsview.cpp that is the problem. It's
the one I added to ~QEvent that checks that the d pointer is still null.
>
> > > I'll add a ### to QEvent saying that the d pointer cannot be used
> > > because
> > > of a hack in graphics view.
>
> d pointer can be used if the graphics view hack is taken in account at the
> time. (example: if there is ever a QEventPrivate, we can change
> QGraphicsView as this point to use it)
Then we should keep the assertion so that the code fails clearly if the
private pointer shows up.
> > Actually, I have a better idea: I'll just add an extra pointer to QEvent
> > for the sole reason of letting QGraphicsView use it.
> >
> > If someone thinks that adding 4 or 8 bytes to EVERY EVENT is a bad idea,
> > please help me come up with a better alternative.
>
> I think it is a bad idea.
>
> My proposed alternative is in the gerrit comments:
>
> - Keep your change that adds the appropriate copy contstructor, but take in
> account the graphicsview hack instead of asserting)
>
> - Maybe even void *extra_ptr is a better name than 'd', as long as its
> usage is internal.
I can reset the pointer back to zero after it's done using. But someone will
have to fix QGraphicsView later if we start using the QEvent private.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
