Getting rid of global objects in kdevplatform/language

[Andreas Pakulat]

On 14.05.10 16:27:07, David Nolden wrote:
> 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.

Even if that is done, that still doesn't mean IndexedString is being used
before Core/SessionController are created. The project model is loaded
_after_ plugincontroller, which is loaded after sessioncontroller.
 
> > 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.

Plugins are no problem. About the efficiency: How often are the three
IndexedString's used that are in language/duchain/? Those are now no global
or static objects anymore and cause no problem.

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

You cannot link to C++ support (and duchainify doesn't), its a plugin and
hence is loaded as plugin.

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

Well, it still is, except that then a different repository is being used
than we'd like to. And QString is quite a bit different as it doesn't need
any resources acquired before it can be used.

I'm open to suggestions for different ways to solve the following two
problems:

- Not being able to easily use valgrind (AFAIK one has to run it on
  kdevelop.bin explicitly)
- Having 2 binaries where one should be sufficient
- Getting rid of those QFSFileEngine warnings, if that fixes the x86_64
  crashes that people have reported

Andreas

-- 
It's a very *__UN*lucky week in which to be took dead.
		-- Churchy La Femme