Pull to refresh

Comments 25

согласен с вами, что подход необычный для анализа возвращаемого значения… можно было бы просто из функции возвращать и проверять… но передо мной встала именно эта проблема, так как функционал писал начальник, а против него не попрешь((
Я не знаток C#.
Попробуйте, пожалуйста, в вашей функции сделать что-нибудь, что требует managed окружения — бросить исключение, например?
вы имеете ввиду функцию «FuncCSharp»??
Нет, я так понимаю, человек хочет попросить Вас провести эксперимент по использованию несколько более сложных функций из стандартного набора .NET
Да, именно из нее. Просто вы не передаете в нее явным образом никакого managed context'а, что может и должно привести к проблемам с исполнением настоящего управляемого кода (исключения, треды).
Как раз не должно. О потоках фреймворк позаботится за вас. Thread.Curent.ManagedId вернет корректный результат, и все прочие функции работы с потоками будут корректно работать.
вобщем, я попробовал(тред и исключение кинуть в функции)… как я и ожидал, ничего не случилось… программа как работала, так и работает… Собственно, ответ на ваш вопрос очень точно описан ниже человеком с ником — kekekeks
Спасибо, надо будет как-нибудь покопаться в этом деле.
Вообще говоря в C# всё нормально с передачей в неуправляемый код указателей на функции и с колбеками из не ассоциированных с managed-окружением потоков. Т. е. оно вам и LPWSTR в System.String переведёт, и результат как надо сконвертит при желании. Единственное, чего нельзя никогда ни при каких обстоятельствах делать — это кидать исключения в unmanaged код из managed-кода и наоборот.
нормально все работает, у нас в аналоге FuncCSharp обращение к БД идет, проблем нет.
Эт вы ещё из C# не работали с псевдо-COM-интерфейсами, которые кидают E_NOTIMPL при попытке вызвать QueryInterface (кстати, это поделие было за авторством мелкомягких и весьма активно использовалось). А CLR его вызывает всегда при попытке скастовать что-либо к интерфейсу. В итоге пришлось ручками расковыривать vtable, создавать делегаты для указателей на методы, а потом ещё и оборачивать всё это безобразие, чтобы скрыть первый параметр. В общем, во взаимодействии managed и unmanaged кода много весёлых вещей есть.
Некоторые проекты, вместо QueryInterface, при сложной изменчивой структуре объектов, используются другие механизмы получения. Например getInterface в XPCOM. То что вы делаете: натурально хак.
Соль в том, что если есть объект IMyCoolObject, который возвращается из функи, то при вызове QueryInterface с IID_IMyCoolObject он должен выдать тот самый IMyCoolObject и никак иначе.
очень интересный подход)
а не пробовали все-таки перевести это дело на C++/CLI?
Проще описать интерфейсы в idl, после чего сгенерить из него входящей в SDK утилитой заголовки для C/C++ и tlbшку для .NET.
да, tlbшки очень помогают. также пробовал. однако иногда легче создать и использовать managed handle, а всю работу завернуть в какую-либо обертку.
не пробовал… если честно, не очень его люблю… Да и задача была поставлена так, что писать именно на C#…
Поиск в интернете по теме вызова managed кода из unmanaged не принес должных плодов
Я конечно извиняюсь но запрос calling managed code from unmanaged вроде должный вариант первым линком выдает.
думаю, что сейчас все можно найти через поиск. в данной статье автор поделился своим опытом. также, как Вы уже заметили, все линки ведут на статьи на английском языке.
Мне кажется эта статья была бы более уместна в блоге .NET
То есть статья просто о маршаллинге делегатов в указатели на функции? Может я оптимист, но от такого громкого названия ожидал большего.
Sign up to leave a comment.

Articles