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