1
class base{
        static base* m_selfInstance;
    public:
        static base* GetInstance();
        virtual void abc() = 0;
    };
    class der:public base{
    public:
        void abc(){cout << "Derived...\n";}
    };
    base* base::m_selfInstance = NULL;
    base* base::GetInstance()
        {
            if(m_selfInstance == NULL)
            {
    /*Throws error here and it's natural, because it's violates C++ standard*/
                    m_selfInstance = new base();    
                }
                return m_selfInstance;
            }
            int main()
            {
                base *b = base::GetInstance();
                //b->abc();
            system("pause");
            return 0;
            }

In this case how to deal with singleton and pure virtual function together. If I'll make like m_selfInstance = new der(); things works fine. But the real problem will occur if there are more derived classes like der_1 and der_2 at that time the istance will be m_selfInstance = new der(); instead of new der_1() or new der_2() . Please guide me how to go ahead with this.

Rasmi Ranjan Nayak
  • 11,510
  • 29
  • 82
  • 122
  • What concrete type _should_ be used, if you have several derived types? – Useless May 14 '13 at 11:31
  • I am afeared by the idea of multiple singletons in a system. – Peter Wood May 14 '13 at 11:32
  • 1
    Consider avoiding usage of singletons, they are bad for many reasons. – nogard May 14 '13 at 11:33
  • @PeterWood: I am trying to do `m_selfInstance = new base();`. I am not looking for multiple singleton and all. But things are not working here that is why I asked this question. I know making `m_selfInstance = new der();` is completely wrong – Rasmi Ranjan Nayak May 14 '13 at 11:35
  • 1
    @nogard, why should anybody avoid singleton? If you need a single instance, the singleton is the way to go. – user1764961 May 14 '13 at 11:37
  • Then what are you exactly trying to achieve ? – JBL May 14 '13 at 11:37
  • @JBL:- I want to get base class instance when ever I want to use base class memebers. But the pure virtual function is not allowing me to create object of abstarct class. so how can I go ahead now. Is there any other solution to deal with this problem. Because I need a single instance anyway. – Rasmi Ranjan Nayak May 14 '13 at 11:41
  • 3
    @user1764961: Many reasons. google "why singleton bad", one of the good discussion [here](http://stackoverflow.com/questions/1020312/are-singletons-really-that-bad) – nogard May 14 '13 at 11:41
  • @RasmiRanjanNayak Then why do you declare your function pure virtual ? If the base class needs and has a reason to be instantiated, then why not making it non-abstract ? – JBL May 14 '13 at 11:43
  • @JBL:- you are right. But I don't wanna give any definition to `abc()`, that is why I made it pure virtual. And I understood that if I won't get any solution then I will go ahead with `virtual void abc(){/*No Body to avoid abstract type*/}` – Rasmi Ranjan Nayak May 14 '13 at 11:46
  • 2
    @user1764961: "why should anybody avoid singleton?" In general: because it couples users of a class to a concrete implementation rather than an abstract interface (making unit testing difficult, for example); and it forces a redesign when you realise that you do need more than one instance. Specifically to C++: because it's surprisingly difficult to manage the object's lifetime safely and correctly. – Mike Seymour May 14 '13 at 11:47
  • @RasmiRanjanNayak Giving no definition to your function isn't the way to go as it means that you have a function that "does nothing until redefined by a sub-class". And that's bad from an interface point of view. The client code won't know the implementation details of your object, thus it's bad to give them a function that "when implemented by this class does something, but when implemented by this class does nothing". It'll work from a language point of view, but it doesn't feel right from an interface point of view (though before anyone complaints, I know there might be specific cases.....) – JBL May 14 '13 at 11:52
  • @user1764961 Are you suggesting we make all classes singletons until we find we need more than one instance? – Peter Wood May 14 '13 at 11:54
  • @PeterWood: No only Base class to be singleton – Rasmi Ranjan Nayak May 14 '13 at 11:56
  • @JBL: Are you suggesting me that, I should stay away from singleton here? – Rasmi Ranjan Nayak May 14 '13 at 11:57
  • @RasmiRanjanNayak You should stay away from singleton as much as possible anyway. Many comments point to a ton of reasons why (I personnaly really like [this discussion on the topic](http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons) and not only the first answer). At least, I think you should reconsider your design. – JBL May 14 '13 at 12:04
  • 4
    @Mike Seymour, the final point is solving the problem. At least I'm paid for it. In cases where I need singleton patter I use it. I guess that's why people invented it. Difficult unit testing is not a reason for avoiding it. Btw, I don't find it difficult. Redesign when you realize that you need more instances is bad design and it has nothing to do with the singleton. Whatever you offer as a reason doesn't really stand from my point of view. It's more like being a slave to some book author. Reading a book is one thing and solving real problems is something completely different. – user1764961 May 14 '13 at 12:18
  • @Peter Wood, can you please show me where did I say that? – user1764961 May 14 '13 at 12:19
  • @user1764961 I was being slightly facetious. The word 'need' is ambiguous. I often have classes which are only instantiated once in my system. I only need one, but I don't need to have only one. Your sentence could be taken to mean that objects which you only need one of, should be singletons. – Peter Wood May 14 '13 at 12:24
  • 1
    @user1764961: Indeed, practice is different from theory (in practice, if not in theory). But I've never found a real-world C++ problem that was made significantly easier by a singleton; and I've encountered more than a few situations in which invisible coupling through global variables (whether or not they were dressed as singletons) made testing and refactoring a large project significantly more involved than it should have been, or where the gnarly details of the object's lifetime lead to unnecessarily obscure bugs. But that's just my experience; yours may be different. – Mike Seymour May 14 '13 at 12:25
  • @Peter, come on, we are not kids. Well, at least I'm not. I assume you are a professional developer. So, if that stands, then you should understand my response without any ambiguity at all. But, to say it explicitly, of course I don't suggest using singleton for every object that we create once. I'm referring to object that must not be created more than once. For example, suppose you need an instance of virtual file system. I did use singleton for it and I did like that pattern. I still do. – user1764961 May 14 '13 at 12:29
  • @user1764961: "Redesign when you realize that you need more instances is bad design": indeed. The bad design was choosing a singleton, and embedding the concept of a single object in the design. By allowing as many objects as needed, but only using one if that's what you currently need, you're able to support future needs without a redesign. – Mike Seymour May 14 '13 at 12:30
  • @Mike Seymour, agree with that. So far I never caught myself swearing for using a singleton after some time. I use it only when I need it and it works for me. While it works for me, I'll still use it, because that's the point of it's existence. I mean, at least that's how I see it. – user1764961 May 14 '13 at 12:36
  • @user1764961 What if you want to preview the changes you are making to the virtual file system, what if you want to implement undo. I don't know, I don't want to get into an argument. But I'm unconvinced that you ever really, absolutely, categorically, need to have only one of something, and need to have a single point of access to it. It feels like a solution looking for a problem, and I've only ever had pain using and implementing Singletons, so the 'solution' as it stands doesn't pass muster. – Peter Wood May 14 '13 at 12:56
  • @Peter, well, believe it or not, on that particular device we have only one file system. Also, I don't see why would singleton prevent preview or undo? These features are not related to multiple instantiated objects only. Suppose that you want to create an object for some kind of logging on your system. Why not singleton? The entire application can log reports/warnings/errors through one object. That's what we wanted here. If you had pain with singleton, that doesn't mean that we should all stay away from it. If you use it properly it does what it should do, no surprises. – user1764961 May 14 '13 at 13:45
  • @user1764961 Okay, I don't have time to continue this in a manner satisfactory to both of us as I won't be around for a few hours. But if I ever see you in the lounge, I'll strike up a conversation. Best. – Peter Wood May 14 '13 at 13:52
  • 2
    @Peter, yeah.. I'll bring a few beers. :-) – user1764961 May 14 '13 at 13:57

0 Answers0