KDE/kdevelop/languages/cpp

Hamish Rodda rodda at kde.org
Wed Oct 31 20:28:45 UTC 2007


On Thu, 1 Nov 2007 06:08:11 am Andreas Pakulat wrote:
> On Mittwoch, 31. Oktober 2007, David Nolden wrote:
> > On Wednesday 31 October 2007 17:37:06 Andreas Pakulat wrote:
> > > b) make the constructors of DUChainPointer implicit again, Hamish
> > > made them explicit and I don't really know why, but I didn't feel
> > > like changing that as there might have been a reason for that...
> >
> > Maybe because that's a kind of design rule(see krazy)?
>
> I doubt that, I'd expect Hamish to be knowledgeable enough to know that
> for such a shared-ptr class implicit conversion is actually wanted.
> Unless of course he wanted to turn all API's into using the shared-ptr
> and thus make it easier to find the places where changes are needed.
> Lets wait for his response.

Actually it's the other way around, it's to make sure we know when we're 
creating a smart pointer - you don't want kdevelop to silently be creating 
thousands of smart pointers that aren't needed, eg. if we add api later that 
only takes a smart pointer, you can tell when it starts being used 
inadvertently.

KSharedPtr was made explicit in the days when we tried to make it work without 
having the object depend on KShared, that was so you didn't go from smart 
pointer to plain pointer and back to smart pointer inadvertently (and thus 
create two sets of shared pointers which don't know about each other).  This 
exact situation is not a problem but imho the silent conversion is still a 
worry and why I prefer explicit.

> > Personally I
> > don't really get the sense of that rule, except maybe for the
> > transparency thing that Kris Wong mentioned some time ago on the
> > list, but for me that doesn't apply for smart pointers.
>
> The rule is to make every constructor that needs only 1 argument
> explicit, but only as long as the implicit construction is not wanted.
>
> Its the same for this rule as for any other rule for kde-libraries,
> apply it when it makes sense. For the special cases we have krazy:
> exclude.

I don't use krazy but in this instance I think it is correct (if it does 
indeed suggest that).

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20071101/cf5363b7/attachment.sig>


More information about the KDevelop-devel mailing list