Получение указателя на объект .Net

[6opoDuJIo]

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

[sidristij]

Она и не позволяет: внутри struct не разместить object _field и IntPtr _pointer. Именно поэтому такой изврат. Но она и не должна позволять два ссылочных типа по одному адресу держать :)

[6opoDuJIo]

Ну, а тут так и получается — на одном смещении относительно начала обьекта расположены сразу два поля с разной «идеологией»: ссылочный и знаковый. Такого, по идее, быть не должно — в таком случае clr должна не позволить загрузить такой тип.

[Saladin]

Если во время манипуляций сработает GC, то память, понятное дело, сожмется. При этом наш указатель автоматически перестанет быть валидным.

Надо сказать, что это проблема должна решаться с помощью Pinned объектов. Вот здесь можно почитать хорошую статью.

[sidristij]

Это понятно что pinned все решит. Однако тут все зависит от ситуации: если вам вдруг захотелось взять много указателей, вы сильно фрагментируете SOH. Другими словами, с pinned надо быть аккуратнее :)

[Erty_Hackward]

У меня есть альтернативное предложение для статьи. Возможно, если и не автор, то кто-то другой заинтересуется.
Есть задача — получать хеши алгоритмом Tiger управляемым кодом быстрее чем через pinvoke вызов неуправляемой библиотеки. (проверка целостности файлов в p2p клиенте). Есть множество реализаций на C#, но pinvoke по скорости обходит их всех. Лучшая «оптимизированная» реализация работает примерно в 2 раза медленнее.
Я пытался разобраться в этой несправедливости. После доработок реализация на C# считает на 30% медленнее чем pinvoke. Это лучший результат для полностью управляемого кода из известных мне.

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