Static access to ICore

[Andreas Pakulat]

On 17.11.07 22:14:34, Matt Rogers wrote:
> 
> On Nov 16, 2007, at 3:11 PM, Andreas Pakulat wrote:
> 
> > On 16.11.07 21:03:43, Esben Mose Hansen wrote:
> >> On Friday 16 November 2007 19:35:06 Andreas Pakulat wrote:
> >>
> >>> Huh? Ok, the constructor check would help if one could directly  
> >>> create
> >>> an ICore object, but the destructor check doesn't help with  
> >>> anything, if
> >>> instance != it gets set to 0, if it already is 0, well nothing  
> >>> happens
> >>> in the end.
> >>
> >> Well, as I presume that only one instance is ever created, that  
> >> check is
> >> almost free and would catch the rather fatal bug if it was created  
> >> twice.
> >> Likewise with the destructor: While unlikely, the check is nearly  
> >> free (could
> >> be an assert, even) and is a nice sanity check. I admit I might be  
> >> too
> >> paranoid there. Blame my IT career ;)
> >
> > Hehe, I just added the assert to the constructor, indeed that check is
> > quite cheap and doesn't really hurt.
> 
> Does it have to be an assert? Not nice to have a program crash before  
> we've even seen the UI. I'm assuming of course that an instance of  
> Core gets created before any UI is shown.

IMHO yes, its a really really bad thing when we create 2 instances of
Core (and thus ICore) and we should tell whoever starts the kdevplatform
application. And I don't see a big problem, because the assert only
triggers in debug mode and it allows to see where it comes from. I can
add a comment to the code that explains why the assert is there, so
whoever gets the assert when starting kdevelop, just has to lookup the
code in the platform to find out whats going wrong.

Also we don't necessarily assert before any Ui comes up, think about
some plugin which is really bad behaved and tries to create a second
Core instance by linking to shell. I doubt people try to create 2 Core
instances in their main.cpp.

Andreas

-- 
Exercise caution in your daily affairs.