Singleton vs. something else

[Diredko]

Hello everyone:) Recently I've got a task for which I need some suggestions on best way to implement it. The task is as follows: I need to add a container, existing in single instance only, which will be available in some to other classes in system. The constraint is that however I'm able to modify classes' implementation, the creation of class instances is held inside a framework which is provided as a compiled library only and thus can't be amended and class instances are not available either. For this reason by-the-book Dependency Injection pattern is not applicable here. An alternative approach would be to utilize Singleton pattern, which I personally not a fan of. I'm not sure what is best way do this. Would you guys please share some ideas with me? Thanks))

[Ericool]

class Singleton
{
  static Singleton * m_instance;
  Singleton(void) {}
  ~Singleton(void){}
public:
 static Singleton * instance (void) 
 {
   if( !m_instance)
      m_instance = new Singleton();

   return m_instance;
 }
  void destroy(void)
 {
    if (m_instance)
   {
      delete m_instance;
     m_instance = nullptr;
   }
 }
};

Singleton * Singleton:: m_instance = nullptr;

[shadowmouse]

So you're suggesting a singleton implementation, pointers rather than references, new without any promise of delete and ifs which don't use braces? All of these things are commonly advised against.

[JLBorges]

Use an object a simple function at namespace scope, perhaps?

// header

struct some_container { /* ... */ };

namespace utility
{
    some_container& instance() ;
}

// implementation

some_container& utility::instance()
{
    static some_container& object_created_by_library = ..... ;
    return object_created_by_library ;
}

[Ericool]

@shadowmouse I use pointers there is nothing wrong with that . if with no braces means only one instruction , that is why I add a newline right after. But I will edit the destructor I forgot to add :)

[MiiNiPaa]

For this reason by-the-book Dependency Injection pattern is not applicable here.

Can you write Facade for those classes to add any functionality you need? Or you need classes themselves and wrappers are not applicable there?

If you are going to use singleton, use automatically destroying, thread-safe Meyers singleton. (EDIT: JLBorges suggested similar approach)

class Singleton
{
public:
  static Singleton& instance()
  {
    static Singleton singleton;
    return singleton;
  }
  Singleton(const CMySingleton&) = delete;                 // Prevent copy-construction
  Singleton& operator=(const CMySingleton&) = delete;      // Prevent copy-assignment
  Singleton(CMySingleton&&) = delete;                 // Prevent move-construction
  Singleton& operator=(CMySingleton&&) = delete;      // Prevent move-assignment
// Other non-static member functions
private:
   Singleton() {}                                  // Private constructor
  ~Singleton() {}                                  // Private destructor
};

If you are going to use GoF singleton, register cleanup function (which destroys object) to be called on exit by atexit() handler.

I use pointers there is nothing wrong with that

Using owning raw pointer is a sign of extremely bad style in modern C++. RAII was created in 80s.

Also you forgot copy-move constructor/assigments. And exposed destruction function for everyone to use with no way to determine who is in responsible of destroying object

[Diredko]

@JLBorges thanks for your reply) but would you please explain the benefits of this approach?

@shadowmouse thanks)

@Ericool lol, but next time I'm reporting such an answer.

[MiiNiPaa]

would you please explain the benefits of this approach?

Thread-safe, object is going to be correctly destroyed, requires little extra work to ensure correct operation, hides implementation details.

[Diredko]

@ MiiNaPaa thanks for your suggestion)) unfortunately I have no access to class instances so wrappers won't make it (maybe I misunderstood you). regarding singleton: I would prefer not to use it at, however if this is my best bet, I could change my mind.

[JLBorges]

> but would you please explain the benefits of this approach?

In the worst case, no advantage other than simplicity.

If an object oriented interface is involved, the major benefit is loose coupling.

// header

struct some_interface_provided_by_the_library { virtual ..... };

namespace utility
{
    some_interface_provided_by_the_library& instance() ;
}

// implementation

some_interface_provided_by_the_library& utility::instance()
{
    static some_library_implementation_of_the_interface singleton { /* ... */ } ;
    return singleton ;
}

[Diredko]

@JLBorges thanks))

[MiiNiPaa]

I though only creation is handled by libraries and you can manipulate instances later. If this isn't hte case, then yes, wrappers cannot be used here.

So your best bet is either a singleton or non-creatable class (interface) one instance of each is accessible through function (which gets own copy from some factory) (JLBorges approach).

Another alternative is a PIMPL with shared implementation. Kind of singleton, but you can easily add ability to use several instances without changing interface at all.

[Diredko]

@MiiNaPaa thanks a lot)), btw I've never heard of PIMPL before and your reply made me to google that and I learned something new)