Память C # после исправления и сборщик мусора - PullRequest
0 голосов
/ 01 марта 2019

Я читаю байты из двоичного файла с BinaryReader.Read и использую оператор fixed для «преобразования» байтов в структуру:

[StructLayout(LayoutKind.Sequential, Pack = 1)]
unsafe struct MyStruct
{
    // some variables.. too many to list
    public fixed Byte Software[32];
    public UInt16 FC_Day;
    public UInt16 FC_Year;
    public UInt16 Header_Size; 
    public UInt32 Offset_to_Data;
    // more variables.. too many to list
};

Затем в Main:

byte[] ReadBytes = new byte[227];
MyStruct* Header;
InFile.Read(ReadBytes, 0, 227);
fixed (byte* bHdrPtr = &ReadBytes[0])
{
    Header = (LASHeader*)bHdrPtr;
    //now Header and ReadBytes occupy the same memory
}

На этом этапе любые изменения ReadBytes изменяются Header и наоборот.Насколько я понимаю, оператор fixed освобождает указатель от перемещения в блоке fixed, но теперь структура и байты постоянно будут занимать ту же память, или управление внутренней памятью будет перемещать / перетасовывать адресапо отдельности?т.е. могу ли я доверять структуре после блока fixed, чтобы она указывала на одну и ту же значимую память и не стала случайными байтами или всеми 0?

Ранее я объявлял как bytes[227], так и MyStruct и использовалBuffer.BlockCopy копировать байты из массива в структуру ... это ужасно неэффективно, требуя удвоения памяти и блочной копии каждый раз, когда читаются новые байты, поэтому я бы предпочел перезаписать байты, как я делал в C ++, чтобы сэкономить памятьи, надеюсь, ускорить процесс.

1 Ответ

0 голосов
/ 01 марта 2019

, но структура и байты теперь постоянно занимают одну и ту же память

документы для fixed состояния:

После выполнения кода в операторе все закрепленные переменные отменяются и подвергаются сборке мусора.Поэтому не указывайте на эти переменные вне фиксированного оператора.Переменные, объявленные в фиксированном операторе, ограничиваются этим оператором

Таким образом, нет - изменение не постоянное - оно ограничено только с точностью доfixed заявление.

...