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

2013-04-29 Thread Thiago Macieira
On terça-feira, 30 de abril de 2013 01.01.36, Milian Wolff wrote: > Interestingly I can't find a case cases don't seem to be using > QSharedDataPointer, or am I missing something? Right. None of them use QSharedDataPointer. You can find uses of that in these changes I uploaded during the weekend

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

2013-04-29 Thread Milian Wolff
On Monday 29 April 2013 15:16:29 Thiago Macieira wrote: > On segunda-feira, 29 de abril de 2013 21.52.37, Milian Wolff wrote: > > 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

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

2013-04-29 Thread Thiago Macieira
On segunda-feira, 29 de abril de 2013 21.52.37, Milian Wolff wrote: > 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}. You probably did not

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

2013-04-29 Thread Sune Vuorela
On 2013-04-29, Milian Wolff wrote: > 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? I'm pretty sure this is because QString can be empty and not null. e.g. the difference between QString() the empty string.

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

2013-04-29 Thread Milian Wolff
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 empt