Korrekte Speichersteuerung in gSoap

Question

Ich entwickle gerade Anwendung mit gSoap-Bibliothek und hat einige Missverständnisse der richtigen Verwendung Bibliothek. Ich habe ein Proxy-Objekt (-j-Flag) generiert, das meine eigenen Klassen umschloss, wie Sie unten sehen können. Die Anwendung muss rund um die Uhr funktionieren und sich gleichzeitig mit vielen Kameras (~ 50 Kameras) verbinden, so dass ich nach jeder Anfrage alle temporären Daten löschen muss. Ist es normal, nach jeder Anfrage soap_destroy() und soap_end() aufzurufen? Weil es nach jeder Anfrage zu viel zu tun scheint. Gibt es eine andere Möglichkeit der richtigen Verwendung?

DeviceBindingProxy::destroy() 
{ 
    soap_destroy(this->soap); 
    soap_end(this->soap); 
} 

class OnvifDeviceService : public Domain::IDeviceService 
{ 
public: 
    OnvifDeviceService() 
    : m_deviceProxy(new DeviceBindingProxy) 
    { 
     soap_register_plugin(m_deviceProxy->soap, soap_wsse); 
    } 

    int OnvifDeviceService::getDeviceInformation(const Access::Domain::Endpoint &endpoint, Domain::DeviceInformation *information) 
    { 
     _tds__GetDeviceInformation tds__GetDeviceInformation; 
     _tds__GetDeviceInformationResponse tds__GetDeviceInformationResponse; 

     setupUserPasswordToProxy(endpoint); 
     m_deviceProxy->soap_endpoint = endpoint.endpoint().c_str(); 
     int result = m_deviceProxy->GetDeviceInformation(&tds__GetDeviceInformation, tds__GetDeviceInformationResponse); 
     m_deviceProxy->soap_endpoint = NULL; 
     if (result != SOAP_OK) { 
      Common::Infrastructure::printSoapError("Fail to get device information.", m_deviceProxy->soap); 
      m_deviceProxy->destroy(); 
      return -1; 
     } 

     *information = Domain::DeviceInformation(tds__GetDeviceInformationResponse.Manufacturer, 
           tds__GetDeviceInformationResponse.Model, 
           tds__GetDeviceInformationResponse.FirmwareVersion); 
     m_deviceProxy->destroy(); 
     return 0; 
    } 

} 

Answer 1

Die Art und Weise, wie Speicher verarbeitet werden muss, ist in Section 9.3 of the GSoap documentation beschrieben.

Answer 2

Um eine korrekte Zuweisung und Freigabe von verwalteten Daten zu gewährleisten:

soap_destroy(soap); 
soap_end(soap); 

Sie wollen dies oft tun Speicher zu vermeiden, mit alten Daten zu füllen. Diese Aufrufe entfernen alle deserialisierten Daten und Daten, die Sie mit den Funktionen soap_new_X() und soap_malloc() zugewiesen haben.

Alle verwalteten Zuordnungen werden mit soap_destroy() gefolgt von soap_end() gelöscht. Danach können Sie wieder die Zuteilung beginnen und wieder löschen usw.

Um verwalteten Daten zuordnen:

SomeClass *obj = soap_new_SomeClass(soap); 

Sie soap_malloc für rohe verwaltete Zuordnung verwenden können, oder ein Array von Zeigern zu vergeben, oder eine C string:

Denken Sie daran, dass Malloc in C++ nicht sicher ist. Besser ist die Zuweisung von std :: string mit:

Arrays können mit dem zweiten Parameter, z. ein Array von 10 Saiten:

std::string *s = soap_new_std__string(soap, 10); 

Wenn Sie Daten zu erhalten, die mit diesen Anrufen wird sonst gelöscht, verwendet:

soap_unlink(soap, obj); 

Jetzt kann obj später mit delete obj entfernt werden. Beachten Sie jedoch, dass alle Zeigerelemente in obj, die auf verwaltete Daten verweisen, nach soap_destroy() und soap_end() ungültig geworden sind. So müssen Sie möglicherweise soap_unlink() auf diesen Mitgliedern aufrufen oder riskieren, Zeiger zu hängen.

Ein neues cooles Feature von gSOAP ist tief Kopieren und Löschen-Funktion für beliebige Datenstrukturen automatisch zu erzeugen, die eine riesige Menge an Codierung Zeit spart:

SomeClass *otherobj = soap_dup_SomeClass(NULL, obj); 

Diese obj auf nicht verwalteten Heap-Speicher kopiert. Dies ist eine tiefe Kopie, die im Objektgraphen nach Zyklen sucht und solche Zyklen entfernt, um Löschprobleme zu vermeiden. Sie können auch das gesamte (zyklische) verwaltete Objekt in einen anderen Kontext duplizieren, indem Sie soap anstelle von NULL für das erste Argument soap_dup_SomeClass verwenden.

Zu tief löschen:

soap_del_SomeClass(obj); 

Dies löscht obj, sondern auch die Daten, auf die von ihren Mitgliedern, und so weiter.

Um die soap_dup_X und soap_del_X Funktionen soapcpp2 -Ec und -Ed, mit Optionen bzw. verwenden zu verwenden.

Prinzipiell können statische und stack-allokierte Daten genauso serialisiert werden. Verwenden Sie stattdessen stattdessen den verwalteten Heap.

Weitere Details und Beispiele finden Sie unter https://www.genivia.com/doc/databinding/html/index.html#memory2.

Hoffe, das hilft.