CODEWITHSUNDEEP
c++singleton
Flavien Volken
Flavien Volken

Reputation: 21339

Avoiding singletons in plugins to be shared among all the instances

I'm building a plugin which will be used in a host. This plugin is using a singleton for services I would like to easily access anywhere. The problem comes when I instance several times the same plugin, the same (static) singleton, being specific to the runnable, will be shard among all the instanced plugins. Is there, generally speaking, a way to reduce the scope of the singleton (c++) ? As each plugin is an instance in itself, I could obviously pass the root class of the plugin to all of it's subclasses but I would like to keep the same global singleton design as possible.

Upvotes: 3

Views: 297

Answers (2)

Flavien Volken
Flavien Volken

Reputation: 21339

A singleton do internally make use of a static variable. The scope of this static variable is specified by the source file where it is defined and partitioned by its current runnable. For those reason, while running under the same host (and then the same runnable) both plugins (which are the same code) do share the same static variable (and by extension the same singleton). As we assume in this question the code to be the same for each plugin, the only way to split those singletons would then be to run a new executable. This could be done using the fork unix command for example where both process will then hold their own memory range. Obviously (as most of you commented) it is a much better approach to avoid using singletons in this case as forking a process is just adding useless complexity.

Upvotes: 0

Open AI - Opting Out
Open AI - Opting Out

Reputation: 24163

Is there a reason for having a singleton? The rationale is when you need to enforce that there is only one, and need to provide a single point of access. If these aren't really requirements, then just create one and pass it around where needed.

I would gradually get rid of the singleton.

Does the singleton do a lot, or not much?

You might need to divide it up into parts.

If it doesn't do much, just pass it where is is needed, and get rid of its singleton-ness.

If it provides lots of services, create interfaces for each service and pass those around where they are needed. Your design will improve and become more testable and easier to comprehend.

At first, the implementations of the interfaces could delegate to the original singleton, but you want to make them self contained eventually.

Upvotes: 3

Related Questions