OGRE-Next  3.0.0unstable
Object-Oriented Graphics Rendering Engine
Ogre::DynLibManager Class Reference

Manager for Dynamic-loading Libraries. More...

#include <OgreDynLibManager.h>

+ Inheritance diagram for Ogre::DynLibManager:

Public Member Functions

 DynLibManager ()
 Default constructor. More...
 
virtual ~DynLibManager ()
 Default destructor. More...
 
DynLibload (const String &filename, const bool bOptional)
 Loads the passed library. More...
 
void unload (DynLib *lib)
 Unloads the passed library. More...
 
- Public Member Functions inherited from Ogre::Singleton< DynLibManager >
 Singleton ()
 
 ~Singleton ()
 

Static Public Member Functions

static DynLibManagergetSingleton ()
 Override standard Singleton retrieval. More...
 
static DynLibManagergetSingletonPtr ()
 Override standard Singleton retrieval. More...
 
- Static Public Member Functions inherited from Ogre::Singleton< DynLibManager >
static DynLibManagergetSingleton ()
 
static DynLibManagergetSingletonPtr ()
 

Detailed Description

Manager for Dynamic-loading Libraries.

Remarks
This manager keeps a track of all the open dynamic-loading libraries, opens them and returns references to already-open libraries.

Constructor & Destructor Documentation

◆ DynLibManager()

Ogre::DynLibManager::DynLibManager ( )

Default constructor.

Note

Should never be called as the singleton is automatically created during the creation of the Root object.
See also
Root::Root

◆ ~DynLibManager()

virtual Ogre::DynLibManager::~DynLibManager ( )
virtual

Default destructor.

See also
Root::~Root

Member Function Documentation

◆ getSingleton()

static DynLibManager& Ogre::DynLibManager::getSingleton ( )
static

Override standard Singleton retrieval.

Remarks
Why do we do this? Well, it's because the Singleton implementation is in a .h file, which means it gets compiled into anybody who includes it. This is needed for the Singleton template to work, but we actually only want it compiled into the implementation of the class based on the Singleton, not all of them. If we don't change this, we get link errors when trying to use the Singleton-based class from an outside dll.
This method just delegates to the template version anyway, but the implementation stays in this single compilation unit, preventing link errors.

◆ getSingletonPtr()

static DynLibManager* Ogre::DynLibManager::getSingletonPtr ( )
static

Override standard Singleton retrieval.

Remarks
Why do we do this? Well, it's because the Singleton implementation is in a .h file, which means it gets compiled into anybody who includes it. This is needed for the Singleton template to work, but we actually only want it compiled into the implementation of the class based on the Singleton, not all of them. If we don't change this, we get link errors when trying to use the Singleton-based class from an outside dll.
This method just delegates to the template version anyway, but the implementation stays in this single compilation unit, preventing link errors.

◆ load()

DynLib* Ogre::DynLibManager::load ( const String filename,
const bool  bOptional 
)

Loads the passed library.

Parameters
filenameThe name of the library. The extension can be omitted.
bOptionalWhen true, we will skip it if it fails to initialize

◆ unload()

void Ogre::DynLibManager::unload ( DynLib lib)

Unloads the passed library.

Parameters
libThe library.

The documentation for this class was generated from the following file: