Search Results

Search found 774 results on 31 pages for 'singleton'.

Page 6/31 | < Previous Page | 2 3 4 5 6 7 8 9 10 11 12 13  | Next Page >

  • Is this a correct implementation of singleton C++?

    - by Kamal
    class A{ static boost::shared_ptr<A> getInstance(){ if(pA==NULL){ pA = new A(); } return boost::shared_ptr(pA); } //destructor ~A(){ delete pA; pA=NULL; } private: A(){ //some initialization code } //private assigment and copy constructors A(A const& copy); // Not Implemented A& operator=(A const& copy); // Not Implemented static A* pA; }; A* A::pA = NULL;

    Read the article

  • General question about Ruby Eigenclass/Singleton

    - by Dex
    module MyModule def my_method; 'hello'; end end class MyClass class << self include MyModule end end MyClass.my_method # => "hello I'm unsure why "include MyModule" needs to be in the eigenclass in order to be called using just MyClass. Why can't I go: X = MyClass.new X.my_method How is this type of pattern useful if I can't call it from an instance?

    Read the article

  • Cocoa Singleton conventions

    - by MikeyWard
    Cocoa is full of singletons. Is there a logical/conventional difference between when the Cocoa APIs use NSSingletonObject *so = [NSSingletonObject defaultSingleton]; versus NSSingletonObject *so = [NSSingletonObject sharedSingleton]; ? Not a huge thing, but I don't really see why sometimes one is used versus the other.

    Read the article

  • Alternative to singleton for unique resources

    - by user1320881
    I keep reading over and over again that one should avoid using singletons for various reasons. I'm wondering how to correctly handle a situation where a class represents a unique system resource. For example, a AudioOutput class using SDL. Since SDL_OpenAudio can only be open once at a time it makes no sense having more then one object of this type and it seems to me preventing accidentally making more then one object would actually be good. Just wondering what experienced programmers think about this, am i missing another option ?

    Read the article

  • C#: System.Lazy&lt;T&gt; and the Singleton Design Pattern

    - by James Michael Hare
    So we've all coded a Singleton at one time or another.  It's a really simple pattern and can be a slightly more elegant alternative to global variables.  Make no mistake, Singletons can be abused and are often over-used -- but occasionally you find a Singleton is the most elegant solution. For those of you not familiar with a Singleton, the basic Design Pattern is that a Singleton class is one where there is only ever one instance of the class created.  This means that constructors must be private to avoid users creating their own instances, and a static property (or method in languages without properties) is defined that returns a single static instance. 1: public class Singleton 2: { 3: // the single instance is defined in a static field 4: private static readonly Singleton _instance = new Singleton(); 5:  6: // constructor private so users can't instantiate on their own 7: private Singleton() 8: { 9: } 10:  11: // read-only property that returns the static field 12: public static Singleton Instance 13: { 14: get 15: { 16: return _instance; 17: } 18: } 19: } This is the most basic singleton, notice the key features: Static readonly field that contains the one and only instance. Constructor is private so it can only be called by the class itself. Static property that returns the single instance. Looks like it satisfies, right?  There's just one (potential) problem.  C# gives you no guarantee of when the static field _instance will be created.  This is because the C# standard simply states that classes (which are marked in the IL as BeforeFieldInit) can have their static fields initialized any time before the field is accessed.  This means that they may be initialized on first use, they may be initialized at some other time before, you can't be sure when. So what if you want to guarantee your instance is truly lazy.  That is, that it is only created on first call to Instance?  Well, there's a few ways to do this.  First we'll show the old ways, and then talk about how .Net 4.0's new System.Lazy<T> type can help make the lazy-Singleton cleaner. Obviously, we could take on the lazy construction ourselves, but being that our Singleton may be accessed by many different threads, we'd need to lock it down. 1: public class LazySingleton1 2: { 3: // lock for thread-safety laziness 4: private static readonly object _mutex = new object(); 5:  6: // static field to hold single instance 7: private static LazySingleton1 _instance = null; 8:  9: // property that does some locking and then creates on first call 10: public static LazySingleton1 Instance 11: { 12: get 13: { 14: if (_instance == null) 15: { 16: lock (_mutex) 17: { 18: if (_instance == null) 19: { 20: _instance = new LazySingleton1(); 21: } 22: } 23: } 24:  25: return _instance; 26: } 27: } 28:  29: private LazySingleton1() 30: { 31: } 32: } This is a standard double-check algorithm so that you don't lock if the instance has already been created.  However, because it's possible two threads can go through the first if at the same time the first time back in, you need to check again after the lock is acquired to avoid creating two instances. Pretty straightforward, but ugly as all heck.  Well, you could also take advantage of the C# standard's BeforeFieldInit and define your class with a static constructor.  It need not have a body, just the presence of the static constructor will remove the BeforeFieldInit attribute on the class and guarantee that no fields are initialized until the first static field, property, or method is called.   1: public class LazySingleton2 2: { 3: // because of the static constructor, this won't get created until first use 4: private static readonly LazySingleton2 _instance = new LazySingleton2(); 5:  6: // Returns the singleton instance using lazy-instantiation 7: public static LazySingleton2 Instance 8: { 9: get { return _instance; } 10: } 11:  12: // private to prevent direct instantiation 13: private LazySingleton2() 14: { 15: } 16:  17: // removes BeforeFieldInit on class so static fields not 18: // initialized before they are used 19: static LazySingleton2() 20: { 21: } 22: } Now, while this works perfectly, I hate it.  Why?  Because it's relying on a non-obvious trick of the IL to guarantee laziness.  Just looking at this code, you'd have no idea that it's doing what it's doing.  Worse yet, you may decide that the empty static constructor serves no purpose and delete it (which removes your lazy guarantee).  Worse-worse yet, they may alter the rules around BeforeFieldInit in the future which could change this. So, what do I propose instead?  .Net 4.0 adds the System.Lazy type which guarantees thread-safe lazy-construction.  Using System.Lazy<T>, we get: 1: public class LazySingleton3 2: { 3: // static holder for instance, need to use lambda to construct since constructor private 4: private static readonly Lazy<LazySingleton3> _instance 5: = new Lazy<LazySingleton3>(() => new LazySingleton3()); 6:  7: // private to prevent direct instantiation. 8: private LazySingleton3() 9: { 10: } 11:  12: // accessor for instance 13: public static LazySingleton3 Instance 14: { 15: get 16: { 17: return _instance.Value; 18: } 19: } 20: } Note, you need your lambda to call the private constructor as Lazy's default constructor can only call public constructors of the type passed in (which we can't have by definition of a Singleton).  But, because the lambda is defined inside our type, it has access to the private members so it's perfect. Note how the Lazy<T> makes it obvious what you're doing (lazy construction), instead of relying on an IL generation side-effect.  This way, it's more maintainable.  Lazy<T> has many other uses as well, obviously, but I really love how elegant and readable it makes the lazy Singleton.

    Read the article

  • Database Context and Singleton injection with IoC

    - by zaitsman
    All of the below relates to a ASP.NET c# app. I have a Singleton Settings MemoryCache that reads values from database on first access and caches these, then invalidates them using SQL Service Broker message and re-reads as required. For the purposes of standard controllers, i create my Db Context in a request scope. However, this obviously means that i can't use the same context in the Settings Cache class, since that is a singleton and we have a scope collision. At the moment, i ended up with two db contexts - the Controllers get it via IoC container, whereas a Singleton just creates it's own. However, i am not satisfied with this approach (mostly due to the way i feel about two contexts, the cache doesn't set anything on the db hence concurrency is not an issue as much). What is a better way to do it?

    Read the article

  • Singleton & Multi-threading

    - by ronan
    Friends I have the following class that class Singleton { private: static Singleton *p_inst; Singleton(); public: static Singleton * instance() { if (!p_inst) { p_inst = new Singleton(); } return p_inst; } }; Please do elaborate on precautions taken while implementing Singleton in multi-threaded environment .. Many thanks

    Read the article

  • Is it possible to apply inheritance to a Singleton class?

    - by Bragaadeesh
    Hi, Today I faced one question in interview. Is it possible to apply inheritance concept on Singleton Classes. I said since the constructor is private, we cannot extend that Singleton class (can someone please validate this). Next thing he asked me is to apply inheritance on that Singleton class. So, I made the Singleton's constructor as protected thinking that child's constructor also has be protected. But I was wrong the child can have a modifier either equal to or higher than that. So, I asked him to give a real world example on such a case. He was not able to give me one and said that I cant ask questions and wanted me to tell whether this scenario is possible or not. I went kind of blank. My question here is, Is this possible? Even if its possible, what is the use of it? What real world scenario would demand such a use. Thanks

    Read the article

  • Can I use an abstract class instead of a private __construct() when creating a singleton in PHP?

    - by Pheter
    When creating a Singleton in PHP, I ensure that it cannot be instantiated by doing the following: class Singleton { private function __construct() {} private function __clone() {} public static function getInstance() {} } However, I realised that defining a class as 'abstract' means that it cannot be instantiated. So is there anything wrong with doing the following instead: abstract class Singleton { public static function getInstance() {} } The second scenario allows me to write fewer lines of code which would be nice. (Not that it actually makes much of a difference.)

    Read the article

  • Constructor and Destructor of a singleton object called twice

    - by Bikram990
    I'm facing a problem in singleton object in c++. Here is the explanation: Problem info: I have a 4 shared libraries (say libA.so, libB.so, libC.so, libD.so) and 2 executable binary files each using one another shared library( say libE.so) which deals with files. The purpose of libE.so is to write data into a file and if the executable restarts or size of file exceeds a certain limit it is zipped and a new file is created with time stamp in name. It is using singleton object. It exports a handler class for getting and using singleton. Compressing only happens in the above said two cases. The user/loader executable can specify the starting name of file only no other control is provided by handler class. libA.so, libB.so, libC.so and libD.so have almost same behavior. They all have a class and declare and object of an handler which gets the instance of the singleton in libE.so and uses it for further purpose. All these libraries are linked to two executable binary files. If only one of the two executable runs then its fine, But if both executable runs one after other then the file of the first started executable gets compressed. Debug info: The constructor and destructor of the singleton object is called twice.(for each executable) The object of singleton is a static object and never deleted. The executable is not able to exit/return gives: glibc detected * (exe1 or exe2): double free or corruption (!prev): some_addr * Running with binaries valgrind gives that the above error is due to the destructor of the singleton object. Thanks

    Read the article

  • Alternatives to the Singleton Design Pattern

    The Singleton Design Pattern is one of the simplest and most widely known design patterns in use in software development. However, despite its simplicity, it is very easy to get wrong and the consequences of its use even when properly implemented can outweigh its benefits. It turns out there are other ways to achieve the goals of the Singleton pattern which will often prove to be simpler, safer, and more maintainable.

    Read the article

  • Hide or Show singleton?

    - by Sinker
    Singleton is a common pattern implemented in both native libraries of .NET and Java. You will see it as such: C#: MyClass.Instance Java: MyClass.getInstance() The question is: when writing APIs, is it better to expose the singleton through a property or getter, or should I hide it as much as possible? Here are the alternatives for illustrative purposes: Exposed(C#): private static MyClass instance; public static MyClass Instance { get { if (instance == null) instance = new MyClass(); return instance; } } public void PerformOperation() { ... } Hidden (C#): private static MyClass instance; public static void PerformOperation() { if (instance == null) { instance = new MyClass(); } ... } EDIT: There seems to be a number of detractors of the Singleton design. Great! Please tell me why and what is the better alternative. Here is my scenario: My whole application utilises one logger (log4net/log4j). Whenever, the program has something to log, it utilises the Logger class (e.g. Logger.Instance.Warn(...) or Logger.Instance.Error(...) etc. Should I use Logger.Warn(...) or Logger.Warn(...) instead? If you have an alternative to singletons that addresses my concern, then please write an answer for it. Thank you :)

    Read the article

  • Singleton Properties

    - by coffeeaddict
    Ok, if I create a singleton class and expose the singleton object through a public static property...I understand that. But my singleton class has other properties in it. Should those be static? Should those also be private? I just want to be able to access all properties of my singleton class by doing this: MySingletonClass.SingletonProperty.SomeProperty2 Where SingletonProperty returns me the single singleton instance. I guess my question is, how do you expose the other properties in the singleton class..make them private and then access them through your public singleton static property?

    Read the article

  • How to bind a control to a singleton in Cocoa?

    - by SphereCat1
    I have a singleton in my FTP app designed to store all of the types of servers that the app can handle, such as FTP or Amazon S3. These types are plugins which are located in the app bundle. Their path is located by applicationWillFinishLoading: and sent to the addServerType: method inside the singleton to be loaded and stored in an NSMutableDictionary. My question is this: How do I bind an NSDictionaryController to the dictionary inside the singleton instance? Can it be done in IB, or do I have to do it in code? I need to be able to display the dictionary's keys in an NSPopupButton so the user can select a server type. Thanks in advance! SphereCat1

    Read the article

  • Do I still have to implement a singleton class by hand in .net, even when using .Net4.0?

    - by Hamish Grubijan
    Once the singleton pattern is understood, writing subsequent singleton classes in C# is a brainless exercise. I would hope that the framework would help you by providing an interface or a base class to do that. Here is how I envision it: public sealed class Schablone : ISingleton<Schablone> { // Stuff forced by the interface goes here // Extra logic goes here } Does what I am looking for exist? Is there some syntactic sugar for constructing a singleton class - whether with an interface, a class attribute, etc.? Can one write a useful and bullet-proof ISingleton themselves? Care to try? Thanks!

    Read the article

  • Is this a valid, lazy, thread-safe Singleton implementation for C#?

    - by Matthew
    I implemented a Singleton pattern like this: public sealed class MyClass { ... public static MyClass Instance { get { return SingletonHolder.instance; } } ... static class SingletonHolder { public static MyClass instance = new MyClass (); } } From Googling around for C# Singleton implementations, it doesn't seem like this is a common way to do things in C#. I found one similar implementation, but the SingletonHolder class wasn't static, and included an explicit (empty) static constructor. Is this a valid, lazy, thread-safe way to implement the Singleton pattern? Or is there something I'm missing?

    Read the article

  • Is there any reason for an object pool to not be treated as a singleton?

    - by Chris Charabaruk
    I don't necessarily mean implemented using the singleton pattern, but rather, only having and using one instance of a pool. I don't like the idea of having just one pool (or one per pooled type). However, I can't really come up with any concrete situations where there's an advantage to multiple pools for mutable types, at least not any where a single pool can function just as well. What advantages are there to having multiple pools over a singleton pool?

    Read the article

  • Could a singleton type replace static methods and classes?

    - by MKO
    In C# Static methods has long served a purpose allowing us to call them without instantiating classes. Only in later year have we became more aware of the problems of using static methods and classes. They can’t use interfaces They can’t use inheritance They are hard to test because you can’t make mocks and stubs Is there a better way ? Obviously we need to be able to access library methods without instantiated classes all the time otherwise our code would become pretty cluttered One possibly solution is to use a new keyword for an old concept: the singleton. Singleton’s are global instances of a class, since they are instances we can use them as we would normal classes. In order to make their use nice and practical we'd need some syntactic sugar however Say that the Math class would be of type singleton instead of an actual class. The actual class containing all the default methods for the Math singleton is DefaultMath, which implements the interface IMath. The singleton would be declared as singleton Math : IMath { public Math { this = new DefaultMath(); } } If we wanted to substitute our own class for all math operations we could make a new class MyMath that inherits DefaultMath, or we could just inherit from the interface IMath and create a whole new Class. To make our class the active Math class, you'd do a simple assignment Math = new MyMath(); and voilá! the next time we call Math.Floor it will call your method. Note that for a normal singleton we'd have to write something like Math.Instance.Floor but the compiler eliminates the need for the Instance property Another idea would be to be able to define a singletons as Lazy so they get instantiated only when they're first called, like lazy singleton Math : IMath What do you think, would it have been a better solution that static methods and classes? Is there any problems with this approach?

    Read the article

  • Achieving C# "readonly" behavior in C++

    - by Tommy Fisk
    Hi guys, this is my first question on stack overflow, so be gentle. Let me first explain the exact behavior I would like to see. If you are familiar with C# then you know that declaring a variable as "readonly" allows a programmer to assign some value to that variable exactly once. Further attempts to modify the variable will result in an error. What I am after: I want to make sure that any and all single-ton classes I define can be predictably instantiated exactly once in my program (more details at the bottom). My approach to realizing my goal is to use extern to declare a global reference to the single-ton (which I will later instantiate at a time I choose. What I have sort of looks like this, namespace Global { extern Singleton& mainInstance; // not defined yet, but it will be later! } int main() { // now that the program has started, go ahead and create the singleton object Singleton& Global::mainInstance = Singleton::GetInstance(); // invalid use of qualified name Global::mainInstance = Singleton::GetInstance(); // doesn't work either :( } class Singleton { /* Some details ommited */ public: Singleton& GetInstance() { static Singleton instance; // exists once for the whole program return instance; } } However this does not really work, and I don't know where to go from here. Some details about what I'm up against: I'm concerned about threading as I am working on code that will deal with game logic while communicating with several third-party processes and other processes I will create. Eventually I would have to implement some kind of synchronization so multiple threads could access the information in the Singleton class without worry. Because I don't know what kinds of optimizations I might like to do, or exactly what threading entails (never done a real project using it), I was thinking that being able to predictably control when Singletons were instantiated would be a Good Thing. Imagine if Process A creates Process B, where B contains several Singletons distributed against multiple files and/or libraries. It could be a real nightmare if I can not reliably ensure the order these singleton objects are instantiated (because they could depend on each other, and calling methods on a NULL object is generally a Bad Thing). If I were in C# I would just use the readonly keyword, but is there any way I can implement this (compiler supported) behavior in C++? Is this even a good idea? Thanks for any feedback.

    Read the article

  • using a Singleton to pass credentials in a multi-tenant application a code smell?

    - by Hans Gruber
    Currently working on a multi-tenant application that employs Shared DB/Shared Schema approach. IOW, we enforce tenant data segregation by defining a TenantID column on all tables. By convention, all SQL reads/writes must include a Where TenantID = '?' clause. Not an ideal solution, but hindsight is 20/20. Anyway, since virtually every page/workflow in our app must display tenant specific data, I made the (poor) decision at the project's outset to employ a Singleton to encapsulate the current user credentials (i.e. TenantID and UserID). My thinking at the time was that I didn't want to add a TenantID parameter to each and every method signature in my Data layer. Here's what the basic pseudo-code looks like: public class UserIdentity { public UserIdentity(int tenantID, int userID) { TenantID = tenantID; UserID = userID; } public int TenantID { get; private set; } public int UserID { get; private set; } } public class AuthenticationModule : IHttpModule { public void Init(HttpApplication context) { context.AuthenticateRequest += new EventHandler(context_AuthenticateRequest); } private void context_AuthenticateRequest(object sender, EventArgs e) { var userIdentity = _authenticationService.AuthenticateUser(sender); if (userIdentity == null) { //authentication failed, so redirect to login page, etc } else { //put the userIdentity into the HttpContext object so that //its only valid for the lifetime of a single request HttpContext.Current.Items["UserIdentity"] = userIdentity; } } } public static class CurrentUser { public static UserIdentity Instance { get { return HttpContext.Current.Items["UserIdentity"]; } } } public class WidgetRepository: IWidgetRepository{ public IEnumerable<Widget> ListWidgets(){ var tenantId = CurrentUser.Instance.TenantID; //call sproc with tenantId parameter } } As you can see, there are several code smells here. This is a singleton, so it's already not unit test friendly. On top of that you have a very tight-coupling between CurrentUser and the HttpContext object. By extension, this also means that I have a reference to System.Web in my Data layer (shudder). I want to pay down some technical debt this sprint by getting rid of this singleton for the reasons mentioned above. I have a few thoughts on what an better implementation might be, but if anyone has any guidance or lessons learned they could share, I would be much obliged.

    Read the article

  • C++ Singleton design pattern.

    - by Artem Barger
    Recently I've bumped into realization/implementation of Singleton design pattern for C++. It has looked in the following way (I have adopted it from real life example): // a lot of methods is omitted here class Singleton { public: static Singleton* getInstance( ); ~Singleton( ); private: Singleton( ); static Singleton* instance; }; From this declaration I can deduce that instance field is initiated on the heap, that means there is a memory allocation. That is completely unclear for me is when does exactly memory is going to be deallocated? Or there is a bug and memory leak? It seems like there is a problem in implementation. PS. And main question how to implement it in the right way?

    Read the article

  • super(type,subclass) in simple singleton implementation

    - by Tianchen Wu
    when I was implementing naive singleton in python, I came up with a problem with super key word. As usual the behavior of super is always tricky and buggy, hope someone can shed light on it. Thanks :) The problem is that: class Singleton(object): def __new__(cls,*args,**kw): if not hasattr(cls,'_instance'): #create a instance of type cls, origin=super(Singleton,Singleton).__new__(cls,*args,**kw) cls._instance=origin return cls._instance class B(Singleton): def __init__(self,b): self.b=b It actually works, but I am wondering Will it be better if I change line 5 to the below, like in most of the books? origin=super(Singleton,cls).__new__(cls,*args,**ks) what's the difference to make?

    Read the article

< Previous Page | 2 3 4 5 6 7 8 9 10 11 12 13  | Next Page >