Getting rid of global objects in kdevplatform/language

Milian Wolff mail at milianw.de
Fri May 14 14:47:42 UTC 2010


Andreas Pakulat, 14.05.2010:
> On 14.05.10 15:31:21, David Nolden wrote:
> > Anyway, of course I guess we can simply enforce the initialization of
> > the duchain repositories as soon as we've set its parameters correctly
> > (session etc.). We will just have to make sure that nobody tries to
> > use the repositories before that happens.
> 
> I'll take this mail as sample for this. As the sessioncontroller is
> actually the very, very first thing that gets created by core, having it
> initialize the duchain repos should be enough.

I disabled loading of the session controller for non-UI mode. So either we'll 
have to do the separation of the UI <-> Core interfaces first or put it 
somewhere else.

I find it strange though that something in the language-part is initialized in 
the session controller.

And aren't the language plugins (supposed) to be loaded from the 
LanguageController? Hence why not put the DUChain initialization there?

> The only two ways I can think of that could then access the repository
> before its initialized properly are:
> 
> a) the main application access IndexedString (or something else that needs
> a repository), which is a brain-dead thing in the app's code

As David said, using global static Indexed* is actually good for performance 
and we use it in all language plugins.

> b) some other library creates a global static object (or just a global
> object) from one of the types that needs a repository. This should
> be fixed in the libs.
> 
> Can you let me know which function(s) I should call to do the
> initialization from session-controller? Then I'll add the necessary assert
> in the itemrepository code so we catch the above two cases.

I'm interested in whether there are other parts that might break here - lets 
hope not.

> BTW: Changing from standard-mode to the all-declarations-and-uses mode
> actually did make a difference, first the parsing time for kdevplatform was
> around 50s, with the all-in it was 1m40 as in my original mail. But I'll
> double-check tonight.

Afaik KDE sees no difference in one or two dashes. So --f == -f and hence it 
worked.

You can try:
kde4trunk at odin:~/projects/kde4/akonadi|master$ kwrite -version
Qt: 4.6.2
KDE Development Platform: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
KWrite: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
kde4trunk at odin:~/projects/kde4/akonadi|master$ kwrite --version
Qt: 4.6.2
KDE Development Platform: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
KWrite: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
kde4trunk at odin:~/projects/kde4/akonadi|master$ kwrite -v
Qt: 4.6.2
KDE Development Platform: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
KWrite: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
kde4trunk at odin:~/projects/kde4/akonadi|master$ kwrite --v
Qt: 4.6.2
KDE Development Platform: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))
KWrite: 4.4.75 (KDE 4.4.75 (KDE 4.5 >= 20100505))

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100514/8463d303/attachment.sig>


More information about the KDevelop-devel mailing list