Poco::SharedLibrary加载后直接实例化类的可行性及实现疑问

Great question! Let's break this down into two parts to address both your concerns clearly.

1. Is using Poco::SharedLibrary with std::shared_ptr a valid approach? #

Absolutely, this is a solid and valid way to manage dynamic library loading with Poco. Here's why:

• Poco::SharedLibrary handles the low-level details of loading/unloading the dynamic library (.dll on Windows, .so on Linux/macOS) into your process's address space. As long as library_path points to a valid, properly built library, this will work as expected.
• Wrapping it in a std::shared_ptr<Poco::SharedLibrary> is a smart move—it ensures the library stays loaded for as long as any objects created from it are in use. If you were to let the Poco::SharedLibrary instance go out of scope early, the library would be unloaded, and any pointers to classes/functions from it would become invalid (leading to crashes or undefined behavior). Your current setup avoids this risk entirely.
• Since your code runs normally, it means you've already handled the critical step of exporting the necessary symbols (like your ClassFactory instance) from the dynamic library—this is a common pitfall, but you've clearly got that right.

2. Are there any hidden issues with your ClassFactory template? #

Your template implementation follows the classic Factory Method Pattern and is perfectly valid for creating polymorphic objects. That said, there are a few easy-to-miss details worth checking:

• Symbol Export/Import: Ensure your ClassFactory instances are properly exported from the dynamic library and imported in your main application. On Windows, this usually means using __declspec(dllexport) when building the library and __declspec(dllimport) when using it; on Linux/macOS, you might need __attribute__((visibility("default"))) or Poco's cross-platform POCO_EXPORT macro. Your code works now, so you probably have this covered, but it's a common gotcha if you ever rebuild the library or port to another platform.
• Memory Management: Your CreateObj() returns a raw pointer—make sure you're properly cleaning up these objects later. Using std::unique_ptr<Base> or std::shared_ptr<Base> to wrap the returned pointer will prevent memory leaks. For example:

  std::unique_ptr<Base> classobj(factory->CreateObj());
  

  If your Base class has a virtual destructor, deleting the pointer via the base class will correctly destroy the derived ClassObject instance.
• Factory Responsibility for Destruction: Does your AbstractClassFactory<Base> define a DestroyObj(Base*) method? If not, consider adding one. This lets the factory handle destruction (in case the derived class needs special cleanup logic that the base class doesn't know about), which keeps the factory pattern consistent. For example:

  class AbstractClassFactory<Base> {
  public:
      // ... existing methods ...
      virtual void DestroyObj(Base* obj) const { delete obj; }
  };
  

  Then you'd call factory->DestroyObj(classobj); instead of directly deleting the pointer.
• Constructor Flexibility: Right now, CreateObj() only creates instances with the default constructor. If you ever need to pass arguments to ClassObject's constructor, you'll need to extend the template—either by adding template parameters for constructor arguments or overloading CreateObj() with different parameter lists.

Summary #

Your current approach is totally viable and follows good practices for dynamic library loading and object creation. Just keep an eye on the memory management and symbol export details I mentioned, and you'll be in great shape.

内容的提问来源于stack exchange，提问作者daohu527