Overview
Features
Download
Documentation
Community
Add-Ons & Services

Asking for a design tip

A general discussion forum.

Asking for a design tip

Postby Dabos » 01 Feb 2012, 12:17

I need my application to load multiple plugins from multiple dlls. The code I have is working but is ugly.

Actually I'm creating a series of Poco::SharedLibraries with the "new" command. All the pointers are stored in a std::Vector. The application iterates trough the vector and create istances of needed objects. The problem is when the DLL is not found. Because a exception will be thrown.

Code: Select all
try
{
 Vector.push_back(new Poco::SharedLibrary(path));
}
catch(...)
...


the dynamic allocation is ugly, but I don't see any other way to access plugins where the plugin list is specified by the user (so I don't have the chance to specify all the required plugins at compile time).
Dabos
 
Posts: 12
Joined: 21 Nov 2011, 10:07

Re: Asking for a design tip

Postby mws » 01 Feb 2012, 12:46

not a design tip, but one for accurate programming :)

try to create the object - check for validity - push back into the vector if everything is ok.

Code: Select all


Poco::SharedLibrary * somePluginLib = new (Poco::SharedLibrary(path));

if (somePluginLib != null )  // and maybe some more checks...
{
    vector.push_back(somePluginLib);
}





hth
marcel
mws
 
Posts: 3
Joined: 28 Mar 2011, 09:27

Re: Asking for a design tip

Postby Dabos » 01 Feb 2012, 16:52

mws wrote:not a design tip, but one for accurate programming :)

try to create the object - check for validity - push back into the vector if everything is ok.

Code: Select all


Poco::SharedLibrary * somePluginLib = new (Poco::SharedLibrary(path));

if (somePluginLib != null )  // and maybe some more checks...
{
    vector.push_back(somePluginLib);
}



pretty useless. There's no way that pointer will be null, if something fail an exception is thrown and the check will be not executed.
The problem is the exception thrown in the constructor (always avoided in my code throwing in constructors).

I thinked to somethink like that
Code: Select all
class PluginWrapper
{
    Poco::SharedLibrary * myPlugin;

public:

    Poco::SharedLibrary * getPlugin(){  return myPlugin;  }
   
    PluginWrapper(std::string & path)
    {
        try
        {
            myPlugin = new Poco::SharedLibrary(path);
        }
        catch(exc&)
        {
            myPlugin = 0;
        }
    }

    ~PluginWrapper()
    {
        if(myPlugin)
        {
            myPlugin->unload();
            delete myPlugin;
        }
    }
};


The only question now is: If the exception is thrown in the ctor does this cause a memory leach? AFAIK if the allocation is done there's no way to retrieve the pointer and deallocate it. But I don't know if the exception will stop the allocation or not.
Dabos
 
Posts: 12
Joined: 21 Nov 2011, 10:07

Re: Asking for a design tip

Postby codecandy2k » 01 Feb 2012, 21:54

As a tip you should avoid holding free pointers to owned objects. Use Poco::SharedPtr to hold the pointers to your SharedLibrary objects.

As far as your concern about memory leaks in the constructor, you should be okay. When an exception is throw in a constructor, the memory allocated for the object is freed. If the constructor does any memory allocation that is not automatically freed and the constructor will have to do it's own exception catching and freeing of that memory. Poco::SharedLibrary constructor doesn't do any allocations that would be left open when it throws an exception.
codecandy2k
 
Posts: 40
Joined: 03 Dec 2011, 18:48


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests

cron