Добрый всем день,

Формирую ответ на вызов функции внешней компоненты CallAsFunc(...)
в виде:

WCHAR_T** wsOutStr;

wchar_t *wsInStr = L"MyTestStrin";

int iActualSize = ::wcslen(wsInStr)+1;

if(m_iMemory->AllocMemory((void**)wsOutStr, iActualSize * sizeof(WCHAR_T)))
{
    ::convToShortWchar(wsOutStr, wsInStr, iActualSize);
}

pVarRetValue->vt = VTYPE_PWSTR;
pVarRetValue->pwstrVal = *wsOutStr;
pVarRetValue->strLen = iActualSize-1;


В результате имею следующее:

Примерно в 30% вызовов сервер 1С прожевывает строку и выдает результат. В остальных 70% случаев сервер отваливается по таймауту.

Чем длиннее строка, тем хуже соотношение, но если проходит, то проходит вся строка, без обрезаний.
Т.е. выделение памяти вроде бы отрабатывает нормально.

Если все оставляю как есть , только возвращаю число:

pvarRetValue->vt = VTYPE_I4;
pvarRetValue->intVal = 12345;

то все отрабатывает без аварий, волне приемлемо по скорости.

В случае строки , даже если не отвалится сервер, то задержка ответа может быть порядка нескольких секунд. Причем нестабильно, может сразу ответить, а может задержать.

Такое ощущение , что сервер 1С пытается что сделать с этой строкой и у него не всегда получается. Причем заметил, что если строка идет "неправильная", то сервер выдает сообщение о том , что "строка XML не такая". Но у меня не XML, я просто передаю строку.

Кто-нибудь сталкивался с подобной проблемой? Что можно сделать?
Спасибо.

шел бы ты лучше в дворники...

У тебя в конце строки есть ДВА! нулевых байта? Иначе, если их нет, программа ползет по памяти, пока их не встретит, засасывая 2-хбайты, которые могут интерпретироваться как XML-мерзкие (ниже 0013).

Я ваще умиляюсь вашей стойкости, ребята.
Delphi это все делает люто прозрачно.
OleVariant переменной присваиваешь значение из String переменной и ... всё..
Если есть указатель на строку - заводишь string переменную, присваиваешь ей значение из указателя и ... всё...
Потом по проекту пройдешься EurekaLog-ом, пофиксишь утечки памяти и вуаля.

Сишкины слезки.

(2)Спасибо за быстрый ответ,
Надо проверить, первый раз слышу про эту фичу.
Кстати, 32-х битная версия этот код не проглатывает, там сделал по другому, в результате в начале строки всегда выходят два крякозябра , возможно причина одна и та же.
Еще раз спасибо.

(3) Про Дельфи не скажу, но у Шарпа (возможно и у Дельфи тоже) нет возможности "потрогать руками" на системном уровне. Пока задача простая, все удобно,
а как что-то сложное, то C++ рулит. (Конечно, это только мое мнение).

(5) У Дельфи - есть.

Я, кстати, раньше сам думал, что для widestring в конце - 2 байта последнего символа + 1 нулевой байт.
Но недавно формировал строку сам и что-то шло не так.
Помог просмотр куска памяти в Delphi.

Ну и достаточно простого опыта:
http://s020.radikal.ru/i710/1505/58/53b36fbb7a63.png

Кернигана и Ритчи на вас обоих нет, нечестивцы....

(7) это не два символа а один, просто в юникоде

(9) Что непонятного я сказал?

В принципе - все логично, если бы система ориентировалась на 1 нулевой байт, для символа с кодом, кратным 256 - возникала бы неоднозначная ситуация
00 01 = 256
00 02 = 512
00 03 = 768

Никаких байтов там нет и в помине
Каждый символ занимает всегда два байта,поэтому число байт в строке чётное
И,нп самом деле,введение специального типа под символы как раз и предполагало,что никто не будет задумываться о их размере.

(0)
Как у тебя вообще не падает, не понятно.
Надо так:

WCHAR_T* wsOutStr;
...
if(m_iMemory->AllocMemory((void*)&wsOutStr, iActualSize sizeof(WCHAR_T)))
...
pVarRetValue->pwstrVal = wsOutStr;

(13)
Форматирование сожрало два знака '*' во второй строке.

Ещё полезно не забыть про то,что в некоторых системах символы занимают по четыре байта каждый