Use of Boost library classes in kdecore?

[David Jarvie]

On Saturday 07 July 2007 05:57:03 Thomas Zander wrote:
> On Friday 06 July 2007 23:12:22 David Jarvie wrote:
> > There is an important issue in the KTimeZone class and the classes
> > derived from it which needs to be addressed by using reference counted
> > pointers. The most suitable class which I can find is from the Boost
> > library: shared_ptr. This has a necessary facility which KSharedPtr
> > lacks, i.e. the ability to implicitly convert shared_ptr<T> to
> > shared_ptr<U> whenever T* can be implicitly converted to U* (e.g. when
> > U is a base class of T).
>
> I'd much rather see this usecase solved using the Q_D macro and thus
> making the KTimeZone objects implicitly shared.
> Or, maybe even better, have a d-pointer that is ref-counted (I do that in
> KOffice several times, really really useful) so you can update the
> timezones data without making it invalid.

I think that on balance having a ref-counted d-pointer might be the better 
approach. It would have the advantage that it would make it impossible to 
access the KTimeZone data other than through its pointer - using the method I 
proposed, people could (although hopefully wouldn't) still obtain direct 
KTimeZone* pointers and mess things up by using them instead of KTimeZonePtr. 
The disadvantage is that it typically doubles the memory required each time a 
KTimeZone reference is stored, from a pointer to a pointer + int. Because a 
large number of references are likely to be stored in KOrganizer, for 
example, I want to keep the size down. But the trade-off for simplicity of 
both use and implementation is probably worth it.

> > KTimeZone instances from referencing invalid pointers if the KTimeZone
> > instance happens to get deleted somewhere else. This problem has
> > already arisen when iCalendar files are reloaded in kdepimlibs/kcal
>
> Naturally, this seems like a design that could be improved upon; the usage
> of shared pointers IMO works best if you do not delete those instances on
> that reload.  What about updating those instances in-place  instead? That
> surely will save a ripple effect of loads and loads of code having to do
> checking if the shared-pointer is still valid.

I'm intending doing that anyway. But time zones will still disappear when 
calendars are closed, but the KTimeZone instances mustn't be deleted until 
all references to them have gone as well.

> And checking such a thing; well then you should just have used a QPointer.
>
> Bottom line; I would really dislike using boost in kdelibs.  Not that I
> have anything against boost per-see. But lets please keep the level of
> complexity (learning new stuff) to a minimum so people can actually roll
> into hacking on kdelibs a bit easier.  Just because you like boost
> doesn't mean all the potential kdelibs hackers should learn to use it.

I'll go for the ref-counted d-pointer instead. Because there will no longer be 
any need to cope with implicit conversions of ref-counted classes, it should 
hopefully be possible to implement it using QExplicitlySharedDataPointer as 
Thiago suggested.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm