Мы используем Poco в нашем проекте, и мы нашли 3 случая, когда мы смущены poco и его жестом указателя.
В большинстве случаев, когда вы вызываете метод класса poco, он принимает параметр Poco :: SharedPtr<> но иногда он принимает указатель на параметр. После того, как он вступит во владение указателем, создающим SharedPtr<> Внутри своего класса.
Когда-нибудь мы хотели бы предоставить классу poco, сохраняющему право собственности на него. Например, чтобы предотвратить его детрой в конце каждого вызова.
Например, этот класс использует класс poco :: TaskManager для запуска задачи. Но мы должны быть очень осторожны с этим, потому что право собственности на созданный нами объект принадлежит poco :: TaskManager.
CMyClass()
{
m_xplTask = new CXplServiceTask(...);
//task manager take the ownership !! (why ??)
m_taskManager.start(m_xplTask);
}
~CMyClass()
{
//do not delete m_xplTask; because owned by Poco::TaskManager ;-(
}
Другой пример :
Мы используем указатель CRestRequestHandler с именем p в локальном контексте, чтобы предоставить его HTTPServer. но мы должны создавать его при каждом вызове! Если бы мы могли, мы бы предпочли сделать Poco :: ShaaredPtr в элементе a просто вернуть его. Но если мы сделаем это с этим указателем, мы не сможем узнать, является ли указатель живым или нет.
Poco::Net::HTTPRequestHandler* CHttpRequestHandlerFactory::createRequestHandler(const Poco::Net::HTTPServerRequest& request)
{
//do not keep pointers in shared_ptr or somewhere else, because poco take ownership ;-(
if (boost::istarts_with(request.getURI(), m_webSocketKeyword))
return new CWebSocketRequestHandler(m_notificationCenter);
else if (boost::istarts_with(request.getURI(), m_restKeywordBase))
{
CRestRequestHandler * p = new CRestRequestHandler(m_restKeywordBase);
//do some very long init
std::vector< boost::shared_ptr<web::rest::service::IRestService> >::iterator i;
for (i = m_restService.begin(); i != m_restService.end(); ++i)
p->registerRestService(*i);
p->initialize();
return p;
}
else
{
CWebsiteRequestHandler * p = new CWebsiteRequestHandler(m_configDocRoot);
std::map<std::string, std::string>::iterator i;
for (i = m_alias.begin(); i != m_alias.end();++i)
p->configureAlias(i->first, i->second);
return p;
}
}
другой случай касается TCPServerConnectionFactory, уже размещенного в переполнении стека:
Не могу использовать Poco TCPServer и TCPServerConnectionFactory
Почему некоторые методы всегда берут на себя ответственность? Разве невозможно иметь подпись для предоставления SharedPtr<> вместо? Я думаю, что не так много модификаций в poco lib для этого.
Любое объяснение?
Смотрите обсуждение на POCO Forum.