If you declare a copy constructor (even if you define it as deleted in the declaration), no move constructor will be declared implicitly. Cf. C++11 12.8/9: If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if — X does not … Read more
Here’s Meyer’s singleton, a very simple lazily constructed singleton getter: Singleton &Singleton::self() { static Singleton instance; return instance; } This is lazy, and C++11 requires it to be thread-safe. In fact, I believe that at least g++ implements this in a thread-safe manner. So if that’s your target compiler or if you use a compiler … Read more
If you are using C++11, here is a right way to do this: Foo& getInst() { static Foo inst(…); return inst; } According to new standard there is no need to care about this problem any more. Object initialization will be made only by one thread, other threads will wait till it complete. Or you … Read more
Use a Metaclass I would recommend Method #2, but you’re better off using a metaclass than a base class. Here is a sample implementation: class Singleton(type): _instances = {} def __call__(cls, *args, **kwargs): if cls not in cls._instances: cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs) return cls._instances[cls] class Logger(object): __metaclass__ = Singleton Or in Python3 class Logger(metaclass=Singleton): … Read more
I would go for Stateless – the server can generate many instances of the bean and process incoming requests in parallel. Singleton sounds like a potential bottleneck – the default @Lock value is @Lock(WRITE) but may be changed to @Lock(READ) for the bean or individual methods.
As Günter Zöchbauer stated in the comments, each of the three ways you listed of creating singletons are the same. Use your personal preference to choose one. I’m going to add some additional notes: SingletonOne when instantiated looks like any other class. So you could use this one if you want to hide the fact … Read more
As per the comment on your question: I’ve a properties file containing some keys value pairs, which is need across the application, that is why I was thinking about a singleton class. This class will load the properties from a file and keep it and you can use it from anywhere in the application Don’t … Read more
Your second code snippet is, in my opinion, the best way of thread-safe lazily initializing a singleton. It actually has a pattern name Initialization-on-demand holder idiom I would suggest you use it.
In scala 2.10 we can do like this import scala.reflect.runtime.universe val runtimeMirror = universe.runtimeMirror(getClass.getClassLoader) val module = runtimeMirror.staticModule(“package.ObjectName”) val obj = runtimeMirror.reflectModule(module) println(obj.instance)