KDE/kdevelop/languages/cpp

Andreas Pakulat apaku at gmx.de
Wed Oct 31 20:54:35 UTC 2007


On Mittwoch, 31. Oktober 2007, Hamish Rodda wrote:
> 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.

Ok, understood. In that case somebody needs to go through the C++ 
support and fix the "problems" I introduced with the compile-fixes. 
There are quite some occurences where now a smartpointer is created 
just so a duchain-call can be executed. Sometimes this uses a member 
variable as "input", which would be possible to convert to a durable 
smart pointer but that needed more work than I wanted to invest. The 
other occurences are mostly either temporary variables inside a 
function or return values from functions.

Andreas

-- 
You have many friends and very few living enemies.




More information about the KDevelop-devel mailing list