about kde4's smart pointer
Michel Hermier
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
http://lists.kde.org/?l=kde-core-devel&m=113723972022888&w=2
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
guarded.
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
mailing list