Protected destructors and memory leaks

[hubert]

I have just started using Poco and I'm suitably impressed by its depth and usefulness. There are, however, some issues that I'd like to raise and find out why things have been implemented in certain ways.

A lot of classes have protected destructors. This means that you cannot create them on the stack without having to create a "blank" subclass. It also means that you can't use std::auto_ptr or a shared_ptr with them. Looking at some of the sample applications it seems like these classes are often created on the heap using new and are never deleted. Since they aren't deleted then the lack of an accessible destructor doesn't cause a compilation problem. It does, however, cause a memory leak. This may not be an issue for a lot of people since these objects typically live for the lifetime of the application. However, it does seem unnecessarily limiting to prevent stack allocation in this way. Running some of the sample applications under valgrind shows a number of potential leaks and I'd like to eliminate these, just as I strive to eliminate compiler warnings.

Any clues as to why so many destructors are protected and if it would be possible in a future version to remove this restriction?

[alex]

Any clues as to why so many destructors are protected and if it would be possible in a future version to remove this restriction?

Usually, there is a reason for protected destructor. But, if you can point out concrete cases where it would not be appropriate to have destructor protected, we can exchange rationales and see who has the stronger case. So, I encourage you give us concrete examples that bother you, and we'll discuss them.

[guenter]

If a class in POCO has a protected destructor, this usually means that the class uses reference counting for memory management, and that all objects should be referenced through Poco::AutoPtr. By convention, we forbid manual deletion of an object that uses reference counting - the only way to delete such objects is via appropriate use of the release() member function.

Have a Merry Christmas,

Günter

[hubert]

If release() needs to be called in order to clean up a reference-counted resource, then why does HTTPTimeServer.cpp not do so? It leaks memory; there are three calls to new and none to delete or release(). When I teach C++ I try to drill into people an instinctive reaction when they allocate with new to put in place some way of cleaning up that resource. Leaks in C++ are symptoms of a lack of a clear ownership policy. TimeRequestHandlerFactory::createRequestHandler returns a raw pointer instead of a smart pointer (such as auto_ptr, shared_ptr or AutoPtr), which makes this code not exception-safe and prone to leaks. If I replace the raw pointer for the allocation of TimeRequestHandlerFactory by Poco::AutoPtr instead I get compilation errors saying that TimeRequestHandlerFactory has no release() or duplicate() methods (but not for the allocation of HTTPServerParams).

So, how can we make this sample code leak-free and exception safe?

[hubert]

Another example of a protected destructor is IniFileConfiguration. In order to use this on the stack I created a subclass containing only a constructor that forwarded to the IniFileConfiguration c/tr.

Code: Select all

struct MyIniFile : IniFileConfiguration
{
  explicit MyIniFile(const std::string & iniFile) : IniFileConfiguration(iniFile) { }
};


This appears to work just fine when allocated on the stack, so why the need to have a protected d/tr?