Динамические массивы в gSOAP способом C ++, используя вектор STL вместо размера __ptr / __?

Я разрабатываю веб-сервис с использованием gSOAP 2.8.8. Я хотел бы отправить неограниченную последовательность пользовательского типа данных. Я могу реализовать это, следуя раздел 11.11 Руководства пользователя gSOAP вот так:

class ns__InnerType {
std::string someStr;
int someInt;
};
class VectorOfInnerTypes {
ns__InnerType* __ptr;
int __size;
};
void ns__myMethod(VectorOfInnerTypes in, ns__EmptyResponse out);

Это хорошо работает. Тем не менее, так как моя программа на C ++, я бы хотел использовать векторы STL. Из всего, что я прочитал, видно, что gSOAP поддерживает сериализацию векторов. Вот что я считаю, должно работать:

#import "stlvector.h"class VectorOfInnerTypes {
std::vector<ns__InnerType> mylist;
};

soapcpp2 рад компилировать это, и я могу передать вектор C ++ при вызове заглушки myMethod, Однако вот что идет по сети:

<s:Envelope ...>
<s:Body s:EncodingStyle=...>
<q1:myMethod xmlns:q1="urn:ns"/>
</s:Body>
</s:Envelope>

Сравните это с сетевым трафиком, когда я использую __ptr/__size:

<SOAP-ENV:Envelope ...>
<SOAP-ENV:Body ...>
<ns:myMethod>
<mylist xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="ns:InnerType[3]">
<item>...</item>
<item>...</item>
<item>...</item>
</mylist>
</ns:myMethod>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Получить std::vector на работу, я пробовал различные комбинации:

std::vector<ns__InnerType> mylist;
std::vector<ns__InnerType*> mylist;
std::vector<ns__InnerType>* mylist;
std::vector<ns__InnerType*>* mylist;

с реквизитом soap_new_std__vectorTemplate... а также soap_new_ns__InnerType при подготовке данных о клиенте, но улучшения нет. Он отказывается правильно сериализоваться.

Оба когда работает (__ptr/__size) и когда это не так (std::vector), вызов myMethod возвращает код 202 или HTTP принят.

Как я и все, кто использует gSOAP в программе на C ++, используют векторы STL вместо примитива __ptr/__size путь? Любая помощь приветствуется.

3

Решение

Задача ещё не решена.

Другие решения

Других решений пока нет …