Use of Boost library classes in kdecore?

[koos vriezen]

2007/7/7, David Jarvie <lists at astrojar.org.uk>:
> On Friday 06 July 2007 22:42:39 koos vriezen wrote:
> > 2007/7/6, David Jarvie <lists at astrojar.org.uk>:
> > [..]
> >
> > > The reason reference counted pointers are necessary is to prevent users
> > > of 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 - KDateTime
> > > objects which reference a time zone require that the KTimeZone instance
> > > doesn't disappear. It is unrealistic to expect developers in general to
> > > be sufficiently aware of the issue to manage to avoid it. The problem
> > > might only manifest itself occasionally, and it is not necessarily easy
> > > to track down. Use everywhere of a KTimeZonePtr class in place of
> > > KTimeZone pointers would fix this:
> >
> > You have then two different pointers to the same timezone?
>
> Yes, there will frequently be many pointers (many thousands in some cases) to
> the same time zone. Each KDateTime instance which uses the time zone will
> have its own pointer.
>
> > How about adding a comment:
> > // Note the KTimeZone pointerr becomes invalid when you call reload
>
> For KDateTime values, it's simply not practical. They are scattered about all
> over the place in kdepim, and there would be no way of being sure that all
> those which refer to a particular time zone have been deleted. Ensuring that
> the KTimeZone instances are never deleted until all references have
> disappeared is the only safe and practical approach.
>
> > Btw. how many timeszones are there anyhow?
>
> In an iCalendar file, I would guess that there would typically be only a small
> number. There could be other applications in the future which create a much
> larger number of instances (e.g. of KTzfileTimeZone, if historical
> information was required for system time zones).

Ok, I thought there wouldn't be more than 24 unique ones, which would
make a map more obvious ..

> > > typedef shared_ptr<KTimeZone> KTimeZonePtr;
> >
> > Note that this may add other headaches like a pointer ending in two
> > shared pointers
>
> I don't understand.
>
> > and the KTimeZone unaware of its own shared_ptr.
>
> The KTimeZone doesn't have a shared_ptr - it just contains the reference
> counter.

Well if they already have a reference counter, why make another
shared_ptr of it.
Unless you don't get my point, ie. difference between subclassing
KShared vs. shared_ptr, first is aware of it's shared ptr, second
isn't.

Anyhow ..

Koos