Коллеги, привет
Столкнулся с задачей:
C# дёргает запрос в C++/CLI
C++/CLI дергает сишную либу, у которой можно передать void* в качестве пользовательских данных
сишная либа вызывает свой асинхронный код
сишный асинхронный код дёргает callback, который через С++/CLI слушается в C# — туда можно пробросить этот void*, чтобы понимать, к какому запросу относится эта callback-нотификация
Был бы int — проблем нет, но тут int64, а билд всего этого безобразия в 32 bit и никак иначе (т.е. sizeof(void*) равен 4, апгрейд на 64 бита аппаратно невозможен). Как на ваш взгляд элегантней всего пробросить его через эту цепочку managed-unmanaged-managed?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Был бы int — проблем нет, но тут int64. Как на ваш взгляд элегантней всего пробросить его через эту цепочку managed-unmanaged-managed?
немного не понял, какого рода проблемы?
Обычно для этого используют
GCHandle.ToIntPtr(GCHandle.Alloc(@object))
Где @object — все что угодно в нашем AppDomain.
Здравствуйте, samius, Вы писали:
S>S>GCHandle.ToIntPtr(GCHandle.Alloc(@object))
S>
S>Где @object — все что угодно в нашем AppDomain.
Хотелось бы избежать ручного аллока, потому что цепочка асинхронная. В идеале — весь memory management остаётся в руках GC, unmanaged-код получает некий хэндл/индекс/etc., который потом виден в C#-колбэке. Повторюсь, у unmanaged API есть лишь 32-битный "void*" для user-defined param, в который и надо упихнуться нашим int64 за один раз.
И да, забыл упомянуть: unmanaged-код этим user-defined параметром никак не пользуется, кроме как подставляет в параметр асинхронного C#-колбэка.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, samius, Вы писали:
S>>S>>GCHandle.ToIntPtr(GCHandle.Alloc(@object))
S>>
S>>Где @object — все что угодно в нашем AppDomain.
MD>Хотелось бы избежать ручного аллока, потому что цепочка асинхронная.
Не понимаю, чем аллок может мешать асинхронной цепочке. Вообще, конечно, GCHandle это такой грязный пенек для GC, который ему все время придется обходить и при значительном кол-ве GCHandle, могу быть какие-то проблемы.
MD>В идеале — весь memory management остаётся в руках GC, unmanaged-код получает некий хэндл/индекс/etc., который потом виден в C#-колбэке. Повторюсь, у unmanaged API есть лишь 32-битный "void*" для user-defined param, в который и надо упихнуться нашим int64 за один раз.
Так это любой ассоциативный контейнер с ключем int плюс организация хранения свободных индексов.
Я для UserContext-ов использую список массивов фиксированной длины, который растет по необходимости и записывает свободные места в цепочку.
В тривиальном исполнении — комбинация Dictionary<int, T> и Stack<int>.
