Я думаю, что ваши два примера на самом деле только один: free()
должен произойти только в конце процесса, что, как вы указываете, бесполезно, так как процесс заканчивается.
Во втором примере, однако, единственное отличие состоит в том, что вы допускаете неопределенное число malloc()
, что может привести к нехватке памяти. Единственный способ справиться с ситуацией - проверить код возврата malloc()
и действовать соответствующим образом.
Это определенно странно. В качестве обходного пути вы можете использовать
"{0:X}{1:X}{2:X}" -f @($byteArray)
, который, кажется, работает даже после доступа к членам $ byteArray
.
Другой возможный обходной путь может заключаться в сохранении отформатированной строки в переменной и ее повторном использовании.
Я понятия не имею, почему это не работает после доступа к свойству Length
.
Чтобы добавить к загадке:
PS > $a = @(1,2,3)
PS > $b = $a
PS > [object]::ReferenceEquals($a, $b)
True
PS > $a.Length
3
PS > [object]::ReferenceEquals($a, $b)
True
PS > "{0:X}{1:X}{2:X}" -f $a
Error formatting a string: Index (zero based) must be greater than or equal to zero and less than the size of the argum
ent list..
At line:1 char:21
+ "{0:X}{1:X}{2:X}" -f <<<< $a
PS > "{0:X}{1:X}{2:X}" -f $b
123
PS > $b.GetLength(0)
3
PS > "{0:X}{1:X}{2:X}" -f $b
123
PS > [object]::ReferenceEquals($a, $b)
True
Я склонен согласиться с Джаредом в том, что это причуда оператора -f
, который видит переменную как объект, а не как массив , частично поддерживается этим:
PS > $a = @(1,2,3)
PS > "{0:X}{1:X}{2:X}" -f $a
123
PS > "{0:X}{1:X}{2:X}" -f $a.PSObject
Error formatting a string: Index (zero based) must be greater than or equal to zero and less than the size of the argum
ent list..
At line:1 char:21
Если базовый объект неприемлем в качестве параметра, тогда должно быть что-то особенное в том, как $ a
изначально хранится, что делает -f
] счастливый. Но это все еще не объясняет, почему вызов GetLength ()
не влияет на «массивность» $ b
так, как Length
(и ] Rank
) похоже.
Как отмечали другие, использование @ ()
, похоже, работает последовательно.
Ого, это довольно увлекательно. Я поигрался с этим в течение нескольких минут в PowerShell V2, и я не могу найти точную причину, почему это происходит.
Но это не мешает мне строить догадки :)
Проблема в том, что команда -f действительно ожидает массив объектов. Что явно происходит в проблемной строке, так это то, что она интерпретирует $ byteArray как отдельный элемент вместо массива.
Но почему срабатывает с первого раза? Мое подозрение состоит в том, что массив лениво оценивается. До тех пор, пока вы не вызовете метод для типа массива, это просто псевдоним конвейера. По какой-то случайности он работает в первом случае, потому что он просто индексирует существующий конвейер или аргументы. Как только вы позвоните .Length, он объединяет конвейер в объект и, следовательно, последующие вызовы правильно интерпретируют его как массив.
Опять же, это в основном спекуляции. Я настоятельно рекомендую вам сообщить об ошибке при подключении, так как это пахнет ошибкой.