Я не думаю, что существует способ сделать это с любыми встроенными командами. Я предложил бы, чтобы Вы загрузили что-то как Gnuwin32 или UnxUtils и использовали sed
команда (или загрузили [только 115] sed
):
sed -c s/FOO/BAR/g filename
Специальная обработка nil
означает, что вы можете делать следующее:
SomeClass * someObject;
someObject = nil;
[someObject doSomething];
И вы можете быть уверены, что ничего не произойдет.
Итак, почему это important?
В Objective-C отправка сообщения объекту означает указание этому объекту что-то сделать или запрос у этого объекта некоторой информации. Некоторые примеры:
[someObject updateRecords]; // 1
x = [someObject size]; // 2
Строка 1 отправляет someObject
сообщение с именем updateRecords
, а строка 2 отправляет тому же объекту сообщение с именем size
, которое, как ожидается, вернет ценность. Эти сообщения сводятся к вызовам методов, а фактический код, который в итоге запускается, определяется системой времени выполнения Objective-C, поскольку Objective-C является языком с динамической типизацией.
Чтобы определить, какой метод вызывать, система времени выполнения считывает информацию с адреса рассматриваемого объекта ( someObject
в приведенных выше примерах), чтобы определить, к какому классу он относится. Используя эту информацию, он может найти подходящий метод для вызова, и когда все это выяснено, он выполняет код метода.
Если система времени выполнения не обработала nil
как особый случай, он, вероятно, выйдет из строя, если вы попытаетесь выполнить код, показанный вверху. nil
определяется как ноль, поэтому среда выполнения начнет считывать информацию с адреса, хранящегося в нулевой ячейке памяти, что почти гарантированно является нарушением доступа.
Если система времени выполнения не рассматривала nil
как особый случай , возможно, произойдет сбой, если вы попытаетесь выполнить код, показанный вверху. nil
определяется как ноль, поэтому среда выполнения начнет считывать информацию с адреса, хранящегося в нулевой ячейке памяти, что почти гарантированно является нарушением доступа.
Если система времени выполнения не рассматривала nil
как особый случай , возможно, произойдет сбой, если вы попытаетесь выполнить код, показанный вверху. nil
определяется как ноль, поэтому среда выполнения начнет считывать информацию с адреса, хранящегося в нулевой ячейке памяти, что почти гарантированно является нарушением доступа.
Вы можете отправить любое сообщение на nil. Ничего не произошло.
Что именно вы не понимаете в этих документах?
Самое замечательное в обмене сообщениями nil по сравнению с другими языками, такими как C #, заключается в том, что вы можете написать код, который выполняет несколько вызовов методов, не проверяя на каждом шаге nil.
id obj1 = [SomeClass object];
id obj2 = [obj1 doSomething];
id obj3 = [obj2 anotherMethod];
id thingICareAbout = [obj3 doSomethingElse];
Если вы пройдете через несколько шагов, чтобы добраться до thingICareAbout
, он экономит много ненужных строк кода, чтобы не нужно было проверять, являются ли obj1, obj2 и т. д. нулевыми перед их использованием. Вы можете просто проверить, равно ли thingICareAbout
ноль один раз в конце, если вам нужно. Иногда вам даже не нужно этого делать, если ваш код все еще работает, когда он равен нулю (или 0 для примитивных значений).
В C # вам пришлось бы явно проверять, является ли каждый объект равным нулю, настраивать обработку исключений вокруг этот блок кода, или просто надеюсь, что ни один из промежуточных объектов никогда не будет нулевым.
Еще одна вещь, о которой следует помнить (что я только что узнал!), Заключается в том, что 10.5 изменил это поведение - раньше оно было безопасным только для целых чисел и указателей на объекты, а не для структур или значений с плавающей запятой. Из-за этого вы можете увидеть дополнительную проверку ошибок при просмотре другого кода.