Review Request for KDecoration
Martin Gräßlin
mgraesslin at kde.org
Tue Nov 4 13:04:48 GMT 2014
On Tuesday 04 November 2014 13:40:30 Milian Wolff wrote:
> > I'd rather stress "notice that the return value can be nullptr and change
> > during the lifetime of the DecoratedClient".
> >
> > The user can still do
> > Decoration *m_deco = m_client->decoration(); // fails at some point
> >
> > Overmore, the guarded pointer may turn nullptr, but m_client->decoration()
> > return a valid pointer again, right (deco changed)?
> >
> > So the strategy you've to sell is to NOT store the pointer locally - and
> > QPointer does actually the opposite, does it?
>
> I agree with Thomas. Using QPointer does not give you any guarantee about
> correct usage. If you want safety, use shared pointers. A QPointer can still
> be invalid and thus you'll need to check it everywhere you use it.
thanks guys. I'll look into it again and whether we can change the usage to
QSharedPointer. At least for the DecoratedClient pointer in Decoration this
should be doable.
> > >> ::findBridge
> > >
> > > could you please explain why or point me to a web resource describing
> > > it?
> >
> > Make it invisible. Any local helper function, not (supposed to be) used
> > outside the source file probably should be tagged "static".
>
> http://stackoverflow.com/questions/1358400/what-is-external-linkage-and-inte
> rnal-linkage-in-c
ah right, so I just forgot the static.
Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141104/971383dd/attachment.sig>
More information about the kde-core-devel
mailing list