about kde4's smart pointer
michel.hermier at gmail.com
Wed Oct 4 00:16:18 BST 2006
After looking at the mailing list archive, I now remember the reason
behind the see for this explicit constructor. It *solve* a possible
nasty problem with dandling pointers, really hard to debug, if you
don't declare this constructor explicit (it helps at compile time and
at bug hunting time). See
Since all the friendly copy and set operators are available for raw
pointers, you usually use it only at most once at pointer creation.
While I agree, we cannot share all the object we don't control the
source with this class, we can still share them indirectly.
Off topic: I'm currently hacking this class to have an
KImplicitSharedPointer and KExplicitSharedPointer, inherited from a
KSharedPointer. And I'm thinking to implement a solution to make them
2006/10/3, Adriaan de Groot <groot at kde.org>:
> On Tuesday 03 October 2006 16:20, Adriaan de Groot wrote:
> > On Tuesday 03 October 2006 16:10, Cyrille Berger wrote:
> > > On Tuesday 03 October 2006 16:08, Adriaan de Groot wrote:
> > > > DOes this have anything to do with explicit constructor checks? They
> > > > may have gotten in the way here.
> > >
> > > yes it has. But the question is wether it was made on purpose or just to
> > > remove the warning message in the EBN.
> I'd like to focus on the explicitness of the constructor:
> 501697 hermier inline explicit KSharedPtr( T* p )
> is that or is that not a good idea for this kind of shared pointer? I'd like
> comments from people who know something about the intended use of such
> pointers (the change has been in there for a long time though).
More information about the kde-core-devel