Здравствуйте Vi2, Вы писали:

Vi2>

Vi2>extern "C" HRESULT __stdcall f2s( BSTR pszCmdLine )
Vi2>{ 
Vi2>    CComBSTR& szCmdLine = *(CComBSTR*) &pszCmdLine;

Vi2>...

Vi2>    return 0;
Vi2>}
Vi2>

Vi2>И использовать szCmdLine как CComBSTR на всю катушку — никаких проблем (с учётом тех требований к классу, кроме деструктора — он вызываться при таком раскладе не будет).

Можно, но это всё уже делает мой класс.
Может я и изобрёл велосипед, но то что он проще — это точно. То что нужно — делает.
P.S. может это врождённое, но не люблю я эти монстрообразные порождения на все случаи жизни. Другими словами: для чего мне "шнуркозавязыватель, использующий революционные технологии в области атомного взаимодействия межмолекулярных соединений с автооткатом, системой аварийного питания и возможностью работы в полярных условиях. как опция поставляется развязыватель" ? Ну может быть пока не нужно...

Здравствуйте Кирпа В.А., Вы писали:

КВА>>>В классе cobj не хватает перегруженого оператора (char *) потому и не вызывается

M>>Спасибо за скорость. Попробую.
M>>Только непонятно — зачем, если есть перегруженный способ инициализации ?
M>>cobj::cobj()
M>>cobj::cobj(char *)
M>>cobj::cobj(...)
M>>Или это — частный случай ? Хочется знать причину а не только решение

КВА>Компилятору надо вызвать функцию у которой параметр char *

КВА>Ты передаешь параметр клас cobj

КВА>Что ему делать?

Насколько я понял, человек пытается сделать как раз наоборот. У функции параметр типа 'cobj'. Он хочет вызывать ее с параметром типа 'char*'. Для этого никакой оператор приведения типа не нужен. Нужен конвертирующий конструктор. И он у него есть.

Здравствуйте Sinclair, Вы писали:

S>Что-то мне подсказывает, что наиболее вероятная причина косяка — version mismatch. т.е. в длл у функции одна сигнатура, а вызывается она с другой.

Да это вообще неверный подход. Функции, экспортируемые DLL, должны принимать только обычные типы. В противном случае мы либо имеем сплошные проблемы, либо должны явно указать что наша DLL накладывает требования на то, какими должны быть ее пользователи, и встраивать ее в некий каркас (по типу MFC Extension DLL или VCL Packages). Остальные случаи — несопровождаемы.

Здравствуйте Аноним, Вы писали:

... экспортируемые DLL, должны принимать только обычные типы. ...

Похоже что так оно и есть.
Невольно задумаешся — как всё-таки ограничен наш мир ...

Спасибо всем за участие.

Здравствуйте ma3ai, Вы писали:

На самом деле, все, как обычно, просто. Когда ты пробуешь вызывать ff из C++ непосредственно, он, видя определение функции, конструирует из строки объект cobj и передает его (или его копию) в функцию. Т.е. собственно конструирование объекта (вызов перегруженного конструктора) происходит в приложение-хостере, которое грузит DLL. После чего в стеке на входе функции появляется экземпляр объекта. А когда ты вызываешь эту функцию из VB — там ее определяешь, как ff(BSTR). Соотв, передается не экземпляр объекта (или ссылка на него), а просто указатель на строку. И в стеке на входе появляется указатель на строку. И что будет в этом случае — одному богу известно. Но что ничего хорошего — 100%. Говоря проще — объект в данном случае конструирует не DLL, а приложение-хостер. Сишное приложение это делает, т.к. видит 'правильный' тип, а VB видит BSTR — что и честно отдает.

Вообще, использование объектов при передаче параметров в таких случаях ведет ко многим проблемам, используй простые типы. Ну, как крайний случай можно рассматривать передачу объектов-интерфейсов, при условии одинаковости реализации vtable в различных языках программирования. И все равно — при этом передают указатель на интерфейс объекта, но никак не сам объект.

А мир — мир, поверь, очень многообразен.

Успехов.



M>Здравствуйте Аноним, Вы писали:

M>... экспортируемые DLL, должны принимать только обычные типы. ...

M>Похоже что так оно и есть.
M>Невольно задумаешся — как всё-таки ограничен наш мир ...
M>

M>Спасибо всем за участие.
M>