> Den 16-08-2013 11:34, Peter Koek skrev:
> > Suppose that I have objects deriving from QObject and want to control
> > their dynamic allocations for performance reasons. I would overload
> > operator new to allocate them, for example, into a pool. None of this is
> > implemented in any way yet.
> > The objects themselves would now be allocated in the pool. However,
> > since I didn't overload the operator new of QObjectPrivate it would not
> > be allocated into the pool which partly defeats the purpose, as I still
> > have a default allocation.
> > My question is: can I control the way the private parts of Qt
> > (specifically, QObjectPrivate) are allocated?
>
> Not without modifying the Qt sources. It's impossible.
>
> > I'd also like to verify the following statements in the context of an
> > LGPL license. I'd like to keep my source closed, so modifying the Qt
> > source directly is not possible. I'd also rather not derive my own PIMPL
> > object from QObjectPrivate to overload operator new, as it would destroy
> > binary compatibility with future versions of Qt5, even when not using
> > any of the QObjectPrivate members.
>
> As Konstantin already replied, it's not a problem to supply a modified
> Qt under LGPL. Only the modifications to Qt itself has to be supplied.
That's why I wanted my statements verified (or falsified). Thanks for the info
guys!
Just for the record, has anyone ever reported noticeable performance
degradation / heap segmentation when allocating/deallocating many (1000+)
QObject derived types several times throughout the lifetime of an application?
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
