[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Shared pointer usage in Akonadi
From:       Marc Mutz <mutz () kde ! org>
Date:       2007-04-27 16:01:54
Message-ID: 200704271601.55630.mutz () kde ! org
[Download RAW message or body]

[a collegue pointed me here, don't expect me to have resurrected from the 
dead :) ]

On Friday 27 April 2007 13:57, Andreas Gungl wrote:
> Hi,
>
> when compiling kdepim (trunk) I get something like the following error:
> akonadi/plugins/akonadi_serializer_mail.cpp:6:32: error:
> boost/shared_ptr.hpp

apt-get install libboost-dev

> Doesn't Qt have shared pointers?

Only intrusive ones, where the pointed-to object needs to inherit some 
interface, or where it has to provide for reference counting itself.

> Or does Boost have something which is unique?

Well, no. boost::shared_ptr is the role model and an implementation of 
std::tr1::shared_ptr, which e.g. gcc4 already has. So in that way, it's not 
unique. Which is a good thing. It's part of C++0x, and is a shared_ptr that 
has quite a few nice features. Among other things, it's optional deleter 
argument allows it to not only delete the object when the last shared_ptr 
goes out of scope, but perform any user-defined operation on it. You can use 
it on FILE* to call fclose on it, you can use it to hand out mutex-locked 
singleton instances that get unlocked when the current user has finished it's 
series of operations, etc, etc. It also has corresponding weak_ptr, which is 
needed to break cyclic dependencies. In short: it's the best thing since 
sliced bread :) It's also standardized, so come Qt5, you will have zero 
porting overhead, whereas QSharedPtr will likely change again. _And_ it's 
compile-time only, no need to link to anything, or compile boost if you don't 
have a system that comes with packages for it.

> I don't mind installing Boost to compile kdepim from trunk, but I 
> wonder if it's really needed.

Nothing is really needed. Eg., you could implement the same thing inside KDE 
SVN, and call it QNIHSharedPtr, that's the wrong question. The correct 
question is: does it significantly ease the job of the developer that 
introduced it? The answer, if you have ever worked with shared_ptr, is a big 
fat yes. The other correct question is: does it put an undue burdon on the 
user of the software. The answer is a big fat no, since it's a header-only 
library with no runtime requirements, it's widely available (all Linux 
versions less than two years old come with sufficiently recent boost 
packages), and stable (no version problems, it will never change again.

> TIA,
> Andreas

Sorry for the long reply. That is b/c I expect this question to come up more 
often and I wanted to provide as much information as possible without getting 
into rambling, so later discussions can point here.

HTH
Marc
_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]