Getting rid of global objects in kdevplatform/language

David Nolden zwabel at googlemail.com
Fri May 14 14:27:07 UTC 2010


2010/5/14 Andreas Pakulat <apaku at gmx.de>:
> 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.
>
> 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
Why should this be braindead? I think it doesn't happen currently, but
efficiency-wise it might be a good thing to switch the
project-management to IndexedString instead of the slow and fat KUrl
at some point.

> 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.

That's not a bad thing, the opposite is the case. For example in the
C++ parser, it is extremely efficient and simple to create a global
static 'IndexedString myString("myStringString");', and later compare
other indexed strings to indexed myString instead of fiddling with the
string directly, as it just comes down to an integer comparison then.
I guess most of the libraries where such things are useful won't be
loaded directly into shell. They might be loaded into another library
that directly links to shell though, like for example
"duchainify"-like tools that might directly link to the C++ support,
so this will probably cause problems in future.

Initially the idea was that IndexedString could be used transparently
exactly like QString without additional rules like "not as a global
static", "not in library X" or similar, and I think it's not nice to
break this transparency.

> 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 think such an interface doesn't exist currently, just start using
some duchain object. I don't have the code in front of me, but you can
take a look at "GlobalItemRepository" or similar, in itemrepository.h,
which is responsible for picking the session-directory and
initializing it.

Greetings, David




More information about the KDevelop-devel mailing list