PluginManager::instance()

Here’s code

PluginManager* PluginManager::instance()
{
static PluginManager *obj = 0;

if (!obj)
  obj = new PluginManager();

return obj;

}

I don’t like this aproach. Object is made static inside function, and nobody knows when it’s deleted
Probable alternatives: static class memeber, transfered by reference; make all functions giving access to extensions static (obviously, there won’t be different pluginmanagers with different lists)

Regards,
Konstantin

Here’s code

PluginManager* PluginManager::instance()
{
static PluginManager *obj = 0;

if (!obj)
  obj = new PluginManager();

return obj;

}

I don’t like this aproach. Object is made static inside function, and nobody knows when it’s deleted
Probable alternatives: static class memeber, transfered by reference; make all functions giving access to extensions static (obviously, there won’t be different pluginmanagers with different lists)

Regards,
Konstantin

On Saturday 20 February 2010 17:05:44 Konstantin Tokarev wrote:

Here’s code

PluginManager* PluginManager::instance()
{
static PluginManager *obj = 0;

if (!obj)
  obj = new PluginManager();

return obj;

}

I don’t like this aproach. Object is made static inside function, and
nobody knows when it’s deleted Probable alternatives: static class
memeber, transfered by reference; make all functions giving access to
extensions static (obviously, there won’t be different pluginmanagers with
different lists)

THis is a classic singleton pattern. I don’t think I wrote it, but don’t see
anything wrong with it. It ensures there is only one instance in a process,
this instance will be deleted when the application closes.

I think there are patterns that improve on this a little, but I don’t see an
obvious bug or problem with it.

Marcus

On Sun, Feb 21, 2010 at 12:10 AM, Marcus D. Hanwell mhanwell@gmail.com wrote:

On Saturday 20 February 2010 17:05:44 Konstantin Tokarev wrote:

Here’s code

PluginManager* PluginManager::instance()
{
static PluginManager *obj = 0;

if (!obj)
  obj = new PluginManager();

return obj;

}

I don’t like this aproach. Object is made static inside function, and
nobody knows when it’s deleted Probable alternatives: static class
memeber, transfered by reference; make all functions giving access to
extensions static (obviously, there won’t be different pluginmanagers with
different lists)

THis is a classic singleton pattern. I don’t think I wrote it, but don’t see
anything wrong with it. It ensures there is only one instance in a process,
this instance will be deleted when the application closes.

I think there are patterns that improve on this a little, but I don’t see an
obvious bug or problem with it.

I believe I wrote that. While I know there are various reasons why
having a global state are bad, it probably was the easiest option at
the time. The function isn’t documented though, I’ll add documentation
for it now…

Marcus


Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel