0

I want the class to inherit the singleton class. Thus, I need to make the constructor protected rather than private. Also, I know that the static methods cannot be overriden because static are the class members. Now, the question is if I will make the constructor protected, will there be any issue? Is protected constructor in the singleton scenario has a drawback? I am talking in the reference of C++.

user3629119
  • 151
  • 1
  • 9
  • The main drawback is that you have a singleton. http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons – Mike Seymour Nov 20 '14 at 12:37

3 Answers3

0

I don't think making the constructor protected has any drawbacks. The protected access specifier was meant to be used for inheritance.
If you do not make the base class constructor protected, how will you ever create your derived class object?

Below is a simple implementation.

class Base {
public:
    static Base* getInstance() {
        if(Base::_instance == NULL)
            Base::_instance = new Base(); 
        return Base::_instance;
     }
protected:
    Base() {}
private:
    static Base* _instance;
};

in the .cpp file :

Base::_instance = NULL;



class Derived : public Base {
public:
    static Derived* getInstance() { 
        if(instance == NULL)
            _instance = new Derived;
        return _instance;
    }
private:
    static Derived* _instance;
};
Rush
  • 486
  • 2
  • 11
  • 2
    That's not a singleton, it's a memory-leak factory. – Mike Seymour Nov 20 '14 at 13:24
  • @MikeSeymour You are right, but this is a bit harsh. just edit it. – Félix Cantournet Nov 20 '14 at 13:27
  • how is it a memory leak? – Rush Nov 20 '14 at 13:28
  • @Rush You must have a static member pointer. when you create the instance you affect the pointer. in the getInstance() method you need to check if the pointer is NULL. if the pointer is NULL there is not instance and you must create it, if it isn't null just return the pointer. – Félix Cantournet Nov 20 '14 at 13:29
  • @Rush: Each call to `getInstance()` creates a new instance, leaving the user with the responsibility to delete it. The user, having been told it's a singleton, won't think to delete it, so it will be leaked. – Mike Seymour Nov 20 '14 at 13:29
  • @Rush your current approach creates a new instance everytime you call getInstance() and doesn't even delete the old one. This is not a singleton. and there is definitely a memory leak. I'll edit your answer to show you – Félix Cantournet Nov 20 '14 at 13:30
  • @FélixCantournet: I can't edit it, since I've no idea how to transform this weirdness into a sensible example of a singleton with a protected constructor. – Mike Seymour Nov 20 '14 at 13:32
  • @rush did you mean to make instance a static variable? You are still not deleting it anywhere – Lieuwe Nov 20 '14 at 13:37
  • Thanks folks for the suggestion. I was maybe asleep while writing those :) Yes, singletons are supposed to outlive the app/process so no question of deleting them. This is not a full blown singleton, but rather a simple example. – Rush Nov 20 '14 at 13:38
  • I guess that the destructor should also be protected right? – user3629119 Nov 20 '14 at 13:47
0

Short answer : DO NOT. You might have a good reason for using a singleton (unlikely but what the hell). I hardly think you can have a good reason for having a singleton derive from another singleton.

This is completely useless. When you create an instance of Derived you will create an instance of Base.

Just make Deriveda singleton and Base an standard class with a public constructor.

The Singleton desing pattern refers to the interface for create instance of the Class. This only means something for concrete classes that you will instanciate. Not potentially abstract Base classes.

Félix Cantournet
  • 1,941
  • 13
  • 17
0

I think some of the other posts misinterpreted what the OP meant, so I'll just give my two cents :). I think the OP is talking about a construction like the following:

template<class A>
class Singleton // class that defines what is means to be Singleton
{
   private:

   protected:
      Singleton() = default;

   public:
      static A& instance()
      {
         static A a;
         return a;
      }
};

class DerivedSingleton: public Singleton<DerivedSingleton> // Make concrete Singleton
{
   friend Singleton<DerivedSingleton>;
   private:
      DerivedSingleton();
   public:
      void DerivedMethod();
};

// .. some code ...
DerivedSingleton::instance().DerivedMethod(); // call method

In this case I do not see any issues with making the Singleton constructor protected. The only way to get hold of DerivedSingleton is through the instance function of the Singleton class. Whether or not Singleton is a good design pattern I have no opinion on.

Banan
  • 434
  • 6
  • 12