Initialization of QSharedDataPointer's for empty objects (i.e. Foo::Foo(void))

Milian Wolff mail at milianw.de
Mon Apr 29 20:52:37 BST 2013


Hey guys!

On the PIM mailing list was recently a post about excessive memory consumption 
in a data structure which stores multiple shared data objects 
(KABC::Addressee).

Looking at it, I noticed that all the shared data objects always allocate 
their private data, even if it is potentially empty.

This is apparently also the way its being done in the documentation, see [1].

I guess that is a oversimplification and wonder what you all think. Imo, 
classes that use QSharedData should also use the shared_empty/null pattern 
that QString e.g. uses. Otherwise it can be quite costly to create many such 
items even though they are empty.

I.e.: In the ctors that construct an "empty" object do not call "new Private" 
but instead (re-)use a static shared empty object created on the stack - see 
shared_empty and shared_null in qstring.{cpp,h}.

I do wonder though why QString has both, a shared_empty and a shared_null 
object. A single one should suffice for most objects, no?

Does anyone have any experience with this? Are there any pitfalls or downsides 
to the approach taken by QString? I also thought about not initializing the 
QSaredDataPointer at all but that would require a lot of additional code when 
its being used to ensure its only accessed when it is initialized. I think the 
pattern applied in QString is much nicer in that regard.

[1]: http://qt-project.org/doc/qt-4.8/qshareddatapointer.html
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130429/f97b27b8/attachment.sig>


More information about the kde-core-devel mailing list