C# Небезопасный / фиксированный код

Я считаю, что небезопасный код используется, если вы хотите получить доступ к чему-либо вне среды выполнения .NET, т.е. это не управляемый код (без сборки мусора и т. д.). Сюда входят необработанные вызовы Windows API и все такое.

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

Это говорит мне о том, что разработчики .NET framework хорошо поработали над проблемным пространством, убедившись, что среда «управляемого кода» может делать все, что традиционный (например, C++) подход может делать с ее небезопасным кодом / указателями. На случай, если это невозможно, есть небезопасные / фиксированные функции, если они вам понадобятся. Я уверен, что у кого-то есть пример, когда нужен небезопасный код, но на практике это кажется редкостью - в чем, скорее, суть, не так ли? :)

Небезопасно полезно (например) для быстрого получения пиксельных данных из изображения с помощью LockBits. Повышение производительности по сравнению с использованием управляемого API составляет несколько порядков.

Это полезно для взаимодействия с неуправляемым кодом. Любые указатели, передаваемые неуправляемым функциям, должны быть исправлены (иначе говоря, закреплены), чтобы сборщик мусора не переместил базовую память.

Если вы используете P / Invoke, то маршаллер по умолчанию будет закреплять объекты за вас. Иногда необходимо выполнить настраиваемый маршаллинг, а иногда необходимо закрепить объект на время, превышающее продолжительность одного вызова P / Invoke.

Я использовал небезопасные блоки для управления растровыми данными. Доступ к необработанному указателю значительно быстрее, чем SetPixel / GetPixel.

unsafe
{
    BitmapData bmData = bm.LockBits(...)
    byte *bits = (byte*)pixels.ToPointer();
    // Do stuff with bits
}

«fixed» и «unsafe» обычно используются при взаимодействии или когда требуется дополнительная производительность. Т.е. String.CopyTo () использует небезопасные и исправленные в своей реализации.

стиль поведения reinterpret_cast

Если вы немного манипулируете, это может быть невероятно полезно

многие высокопроизводительные реализации хэш-кода используют UInt32 для хэш-значения (это упрощает сдвиги). Поскольку .Net требует Int32 для метода, который вы хотите быстро преобразовать uint в int. Поскольку не имеет значения, каково фактическое значение, желательно только то, чтобы все биты в значении сохранялись, переинтерпретировать приведение.

public static unsafe int UInt32ToInt32Bits(uint x)
{
    return *((int*)(void*)&x);
}

обратите внимание, что именование моделируется на BitConverter.DoubleToInt64Bits

Продолжая хешировать, преобразование структуры на основе стека в байт * позволяет легко использовать побайтовые функции хеширования:

// from the Jenkins one at a time hash function
private static unsafe void Hash(byte* data, int len, ref uint hash)
{
    for (int i = 0; i < len; i++)
    {
        hash += data[i];
        hash += (hash << 10);
        hash ^= (hash >> 6);
    }
}

public unsafe static void HashCombine(ref uint sofar, long data)
{
    byte* dataBytes = (byte*)(void*)&data;
    AddToHash(dataBytes, sizeof(long), ref sofar);
}

unsafe также (начиная с версии 2.0) позволяет использовать stackalloc. Это может быть очень полезно в ситуациях с высокой производительностью, когда требуется небольшой массив переменной длины, например временное пространство.

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

fixed необходим, когда вы хотите взаимодействовать с какой-либо полезной неуправляемой функцией (их много), которая принимает массивы или строки в стиле c. Таким образом, это делается не только из соображений производительности, но и из соображений корректности в сценариях взаимодействия.