Future of teamwork plugin
david.nolden.kdevelop at art-master.de
Wed Jul 4 14:11:20 UTC 2007
Am Mittwoch, 4. Juli 2007 15:39:28 schrieb Kris Wong:
> times, and it is quite a bitch to try to follow. The main problem in this
> code is all of the implicit casts. It's nearly impossible to try to follow
> code when different types "automagically" convert themselves to other
> types. Very rarely does this practice make sense (some examples might be a
In the teamwork-plugin, there is only implicit casts where it is c++-logical.
That means that a shared-pointer is implicitly casted to a normal pointer,
and a shared-pointer can be casted to any parent-class shared-pointer.
I think the only addition to that is the locking-cast.
You're right about kdevelop-3.4 and the implicit casts in the cc-code. There
is a very simple reason for that though: When I started working on the
code-completion there, it already had some quite complicated algorithms in
it, and everything worked with QString's and QStringLists. Since I didn't
plan to rewrite most of it, I simply added some more "intelligent" classes
that seamlessly integrated into the already available code. That especially
ment that they could be implicitly casted to their old, stupider, versions.
So that's mainly a result of the evolution the code has made. :-)
Of course having that many implicit casts later lowered the constraint to add
more of them.
More information about the KDevelop-devel