On Mon, Oct 17, 2011 at 4:00 PM, <[email protected]> wrote: > It doesn't always make sense. While QSharedDataPointer is safe, you have > to be careful with it if you want to optimize for performance to avoid > calling detach() too often. > > The same thing is true in other places in Qt: It's not always the best > idea to implement Qt using Qt. For some core things, hand-crafted data > structures are often better. > > As an example, we managed to squeeze around 30% out of the load times for > QML by replacing some of our generic containers with data structures that > were written and optimized for the use case at hand. And that's not > because the containers we have are bad, but simply due to the fact that > they are general purpose.
There's nothing here that isn't true and speed optimization may indeed require custom or duplicated code. For QString, though, I know that it isn't implemented using QSharedDataPointer simply because QString was there before QSharedDataPointer. I'm not aware of any performance tests that suggest using QSharedDataPointer would be a bad idea in this case. I may be wrong though. My suggestion was based on a labs post by Thiago[0], in which he states about shared data pointer: "This class is the basis of all Qt value-type, implicit-shared, thread-safe copy-on-write recent classes, like QNetworkProxy. The only reason why it isn’t used in the base classes like QByteArray, QString and QList is that those classes were developed before this class was made. There’s nothing technically stopping the retrofitting of those classes with QSharedDataPointer." If people are going to mess about in these classes, this might as well be done/checked with it. Cheers, Frans [0] http://labs.qt.nokia.com/2009/08/25/count-with-me-how-many-smart-pointer-classes-does-qt-have/ _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
