Должны ли вы использовать указатели (небезопасный код) в С#?

Ответ 1

Из самого "Человека":

Использование указателей редко требуется в С#, но есть некоторые ситуации, которые требуют их. В качестве примеров использование небезопасного контекста для указания указателей гарантируется следующими случаями:

• Работа с существующими структурами на диске
• Дополнительные сценарии COM или платформы Invoke, которые включают структуры с указателями в них
• Высокопроизводительный код

Использование небезопасного контекста в других ситуациях не рекомендуется.

В частности, небезопасный контекст не должен использоваться, чтобы попытаться написать код C на С#.

Внимание:

Код, написанный с использованием небезопасного контекста, не может быть проверен как безопасный, поэтому он будет выполнен только тогда, когда код полностью доверен. Другими словами, небезопасный код не может быть выполнен в ненадежной среде. Например, вы не можете запускать небезопасный код непосредственно из Интернета.

Ссылка

Ответ 2

Если вам нужно.

Скажите, что вам нужно сделать ложный цвет большим полутоновым изображением, скажем, 2000x2000 пикселей. Сначала напишите "безопасную" версию с помощью GetPixel() и SetPixel(). Если это работает, отлично, продолжайте. если это окажется слишком медленным, вам может потребоваться получить фактические биты, составляющие изображение (забудьте о цветовых матрицах для примера). Нет ничего плохого в использовании небезопасного кода, но он добавляет сложности проекту и поэтому должен использоваться только при необходимости.

Ответ 3

Я не могу вспомнить, что когда-либо это делал, но я не много сделал. Это самое распространенное приложение, я считаю: вызов в собственный код. Существует несколько раз, когда использование указателей позволяет вам оптимизировать некоторый код, но это довольно редко в моем опыте.

Если это какой-либо справочник, я считаю себя довольно опытным на С#, но если бы мне пришлось делать какой-либо небезопасный код, мне пришлось бы проконсультироваться со спецификацией/книгами/MSDN, чтобы вести меня. Конечно, будет много людей, которые довольны небезопасным кодом, но менее знакомы с (скажем) выражениями запросов...

Ответ 4

Я бы сказал, что основными проблемами являются: -

• Небезопасный код не поддается проверке. Это означает, что код может запускаться только пользователем из полностью доверенного контекста, поэтому, если вам когда-нибудь понадобится пользователь для запуска кода из любого места, где он не может быть полностью доверенным (например, сетевой ресурс не настроен так), вы болты.
• Отсутствие проверяемости (hm not sure, если это фактически слово) также означает, что вы могли бы испортить память в своей программе. Вы потенциально возвращаете целые классы ошибок в ваше приложение - переполнение буфера, оборванные указатели, yada yada yuck yuck. не говоря уже о потенциально возможном повреждении структур данных в памяти, не понимая, когда ваш указатель становится странным.
• Если вы хотите, чтобы ваш небезопасный код обращался к управляемым объектам, вам нужно "привязать" их. Это означает, что GC не позволяет перемещать объект в памяти, и, следовательно, управляемая куча может стать фрагментированной. Это имеет последствия для производительности; поэтому всегда важно определить, не повлияет ли какая-либо потенциальная первичная прибыль на эту проблему.
• Ваш код становится более понятным для программистов, не используемых для неуправляемого подхода. Затем они могут быть более склонны снимать свою ногу с помощью некоторого "безопасного" кода безопасности, который дает им.
• Вы сможете написать код, не отвечающий типу; это действительно устраняет много преимуществ хорошего теплого нечеткого управляемого языка. Теперь вы можете столкнуться с опасными проблемами безопасности. Зачем делать этот шаг назад?
• Это делает ваш код более уродливым.

Я уверен, что больше можно добавить в список; в общем, как говорили другие, - избегайте, если вам не нужно. вызывая неуправляемый метод с помощью p/invoke, который требует некоторого специального поворота указателя. Даже тогда маршаллер будет в основном предотвращать его необходимость, в основном.

"Человек" также говорит, избегая, если это необходимо, в основном.

О, хорошая статья о прикреплении здесь, на MSDN, кстати.

Ответ 5

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

Чтобы сказать, что большинство людей здесь сказали бы "не делай этого". Подавляющее большинство разработчиков .NET не столкнутся с ситуацией в их обычной деятельности, которая может быть решена только с помощью небезопасного кода.

Ответ 6

Я использовал небезопасный код для использования олицетворения, чтобы разрешить доступ к сетевым ресурсам. Это не проблема, если вы знаете, что делаете.

Ответ 7

Вы должны использовать их, если они вам понадобятся; в основном это связано с некоторыми сложными сценариями взаимодействия (например, когда я писал управляемую оболочку для DPAPI в .NET 1.0, они были необходимы), но очень иногда это могло бы улучшить производительность (после профилирования!) с помощью stackalloc или аналогично.

Рекомендуется Microsoft, поскольку они являются разработчиками С#, и они приняли решение добавить возможность писать код unsafe в нем. Вы можете видеть из выбора ключевого слова и требования о разграничении методов/классов, в которых вы пишете его с помощью ключевого слова, что он не предназначен для фактического выбора реализации.

Ответ 8

Реинтерпретирующий, например, приводы, не поставляемые BitConverter.
В частности, преобразование unint в int для хеш-функций, где все, о чем вы заботитесь, это биты.

Используя некоторые полезные, хорошо обоснованные идиоматические функции c или С++ на структурах, где вам нужно рассматривать их как байты * известной длины, снова наиболее полезными для хэширования.

Чрезвычайно быстрая двоичная сериализация (очень специфическая) в структурах памяти (делая это с массивом из них), хотя, честно говоря, это лучше сделать, просто перейдя на С++/CLI.

Надо сказать, что во многих случаях задачу, требующую указателей, часто можно решить лучше, выполняя ее в С++/CLI, а затем импортируя это в проект С# как dll. Он не изменяет, является ли код "безопасным" или нет, но он делает кучу полезных функций для работы с структурами на основе указателей более доступными. Это также позволяет вам общаться с родовыми типами или перечислениями, если вы действительно этого хотите.

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

Ответ 9

Конечно, это не "рекомендуется", поэтому он назвал "небезопасным". Но не позволяйте этому отпугивать вас. Хотя, это должно заставить вас дважды взглянуть на ваш код. Возможно, есть способ для этого?

Ответ 10

Использование небезопасного кода похоже на забывание преимуществ .NET Framework, я использовал их один раз для создания старомодных структур, таких как стеки и прочее, но это было только для школы, в настоящее время у меня нет необходимости использовать их.

Ответ 11

Сделайте это, если это сделает ваш код короче и понятнее.

"Следуйте своим наклонностям с должным учетом полицейского за углом". WSM