Загрузка с++ обертки для си-библиотекив в мт5

 

Есть библиотека, написанная на чистом си - nanomsg.dll

Делаю враппер - nnmql.dll. Создал проект  в VS2013, обернул нужные функции в соответствии с инструкцией "как за 10 минут ...". Из враппера доступ к си библиотеке осуществляется через статическую связь - через .lib файл.

Сделал индикатор в мт5, положил в его директорию и nanomsg.dll и nnmql.dll. Импортировал функции. Все скомпилировалось без ошибок. При запуске индюка в логе импортированная функция возвращается ноль, хотя функция его никоим образом не возвращает, ибо

_DLLAPI int __stdcall nnmql_init(wchar_t *text_url, wchar_t *from, wchar_t *to){
        wchar_t *cp;
        //--- проверка параметров
        if (text_url == NULL || from == NULL || to == NULL) return 0;
        if (wcslen(from) != wcslen(to))             return 0;
        //--- поищем подстроку
        if ((cp = wcsstr(text_url, from)) == NULL)         return 0;
        //--- заменим
        memcpy(cp, to, wcslen(to)*sizeof(wchar_t));
        // Переведем в систроку и вызовим функцию
        char * url_c;
        std::sprintf(url_c, "%S", cp);
        // теперь вызываем обернутые функцию.
        int sock = nnmql_socket(AF_SP, NN_PAIR); // Эта функция не может ноль вернуть: либо положительное, либо -1
        if (nnmql_bind(sock, url_c) != 0) return sock; 
        return 100500; // !!!!!!!
}

Вопросы такие:

- Правильно ли вообще делать с++ враппер через статическую связь с си библиотекой? Не на этом ли мт5 зависает?

- Какие еще есть варианты использовать си функции в мкуэл?

 
Al_key:

Есть библиотека, написанная на чистом си - nanomsg.dll

Делаю враппер - nnmql.dll. Создал проект  в VS2013, обернул нужные функции в соответствии с инструкцией "как за 10 минут ...". Из враппера доступ к си библиотеке осуществляется через статическую связь - через .lib файл.

Сделал индикатор в мт5, положил в его директорию и nanomsg.dll и nnmql.dll. Импортировал функции. Все скомпилировалось без ошибок. При запуске индюка в логе импортированная функция возвращается ноль, хотя функция его никоим образом не возвращает, ибо

Вопросы такие:

- Правильно ли вообще делать с++ враппер через статическую связь с си библиотекой? Не на этом ли мт5 зависает?

- Какие еще есть варианты использовать си функции в мкуэл?

Ибо
 if (text_url == NULL || from == NULL || to == NULL) return 0; <<<
        if (wcslen(from) != wcslen(to))             return 0; <<<
        //--- поищем подстроку
        if ((cp = wcsstr(text_url, from)) == NULL)         return 0; <<<

3 варианта как минимум чтобы вернуть 0.

Самое простое вывести MessageBox перед каждым условием и по его появлению увидите где возврат идет 

 

Бокс показал, что возврат нуля здесь получился.

int sock = nnmql_socket(AF_SP, NN_PAIR);

Я во внутренностях си-либы не копался (видимо придется), но в документации к ней сказано, что функция не возвращает ноль. И поэтому я подумал, что это может особенности подключения либы на си из либы на с++, которая в свою очередь подключена к мт5. Тем более, что таже функция в обычном с++ проекте работает как надо.

 

  - Правильно ли вообще делать с++ враппер через статическую связь с си библиотекой? Не на этом ли мт5 зависает?

Правильно.

  - Какие еще есть варианты использовать си функции в мкуэл? 

Ещё можно написать враппер прямо на MQL.


 

Ну второй вариант исключен при всяких void*, const char * и других сложных типах или нет?

Тут еще одна вещь всплыла: После обновления метатрейдера на текущий билд перестала работать аналогичным образом сделанная обертка библиотеки zmq (до этого все норм было). Может кто сталкивался с подобным?

 

Не исключён.

Указатели легко заменяются на uint, ulong или ссылки. 

 
Al_key:

Ну второй вариант исключен при всяких void*, const char * и других сложных типах или нет?

Тут еще одна вещь всплыла: После обновления метатрейдера на текущий билд перестала работать аналогичным образом сделанная обертка библиотеки zmq (до этого все норм было). Может кто сталкивался с подобным?

Если речь о билде MT5 b1035 x64 и используете wchar_t* для получения строки в MQL из DLL, то проблема известна, в следующем билде исправить обещали.
Причина обращения: