Use of Boost library classes in kdecore?

[koos vriezen]

2007/7/7, David Jarvie <lists at astrojar.org.uk>:
> On Friday 06 July 2007 23:47:05 koos vriezen wrote:
> > 2007/7/7, David Jarvie <lists at astrojar.org.uk>:
> > > On Friday 06 July 2007 23:07:36 koos vriezen wrote:
> > > > 2007/7/7, David Jarvie <lists at astrojar.org.uk>:
> > > > > On Friday 06 July 2007 22:42:39 koos vriezen wrote:
> > > > > > 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 ..
> > >
> > > There are around 400 time zones in the system time zone database.
> >
> > Still a candidate for create on demand, always return the same pointer
> > to the same timezone and never delete (but then again I have no idea
> > how big these are ..)
>
> If somebody is logged in for weeks or months on end, using KOrganizer
> extensively, they could load and reload calendars many times and each time
> create a new set of KTimeZone instances (ICalTimeZone, derived from
> KTimeZone, actually). I think that there needs to be a deletion mechanism for
> unused ICalTimeZone objects in this case, to avoid ever-increasing memory
> usage. Bear in mind that each iCalendar may contain its own time zone
> definitions, which are not guaranteed to be identical to those in other
> iCalendars. So you could end up with far more than 400 time zone instances.

If you think it's more than unlikely that one get far more than 400 at
a given time and later this shrinks significantly than sure. And
comparing with an app that has many duplicates to the same timezone.
Though you can than think of eg a shared memory for all applications
(not for user defined of course).
Well it's your problem of course, I just wanted to point out a much
simpler and faster solution (think of comparing timezones) than having
all the extra complexity you wan to add.

> > > > 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.
> > >
> > > I'm still unclear. Both of them are aware that their pointers are to a
> > > shared data object. The two classes appear to be similar, except that
> > > KSharedPtr is more limited than shared_ptr, and if it were to be used
> > > would need to be subclassed to add the necessary facilities which
> > > shared_ptr already has.
> >
> > No the KShared one can use 'this' to pass to functions that want to
> > store and reference that object. An object that has its 'this' pointer
> > in a shared_ptr can't do that.
>
> To successfully use reference counting, you need to do it as automatically as
> possible.

That's not true.

> KShared (alias QSharedData) doesn't do it itself - it's done by
> KSharedPtr (or QSharedDataPointer, which provides automatic cloning when
> non-const methods are called, which is not appropriate for KTimeZone).
> shared_ptr in the Boost library does a similar thing to KSharedPtr, but
> provides other necessary functionality as well.

Sure.

Koos