Управление памятью и владение при возврате NSString из метода

Я пишу метод в Objective-C, который должен возвращать строку на основе ввода NSMutableArray. Я не собираюсь, чтобы вызывающие абоненты изменяли строку, но мне все равно. Текущая подпись метода выглядит так:

- (NSMutableString *) generateString:(NSMutableArray *)myArray

В настоящее время проект представляет собой Foundation Tool из командной строки, предназначенный для изучения проблем, но в конечном итоге он будет реализован в приложении для iPhone.

Мои вопросы:

  1. Было бы разумнее вернуть NSString?

2) Должен ли я использовать автозапуск при возврате NSMutableString? Если вы рекомендуете вернуть NSString, как это изменит его возврат?

3) Если я также хочу вернуть объект ошибки, идентифицирующий, произошла ли ошибка, возможно, перечисление и строка, как в этом случае работает владение? Метод не называется alloc, new или copy, так как об этом узнает вызывающий? Как мне вернуть выделенный объект ошибки в дополнение к строке в указанном выше методе?

Спасибо!


person BigBrother    schedule 11.01.2011    source источник
comment
просто примечание, не знаю, имеет ли это отношение к вам, но вы можете получить NSString от NSArray вот так: NSString *myString = [myArray componentsJoinedByString:@" "];   -  person filipe    schedule 11.01.2011
comment
Спасибо filipe, я этого не знал. Это отличная идея, но в данном случае она не сработает для меня, поскольку существует необходимая логика, влияющая на то, как создается финальная строка.   -  person BigBrother    schedule 11.01.2011


Ответы (2)


  1. В большинстве случаев я бы вернул NSString. У него немного меньший объем памяти, и если вызывающей стороне нужна изменяемая копия, создание ее - это всего лишь метод: mutableCopy.
  2. Вы не только должны, но и должны автоматически выпустить NSString или NSMutableString, возвращаемый вашим методом (по крайней мере, если вы назовете свой метод, как в примере)! Руководство по программированию управления памятью содержит список правил, которым вы должны следовать, чтобы избежать полного беспорядка, и все подробно объясняет. Так что прочтите!
  3. Платформа Foundation использует класс NSError для описания ошибок. Чтобы «вернуть» дополнительные параметры, ваш метод будет выглядеть так:

    - (NSString *)generateString:(NSMutableArray *)myArray error:(NSError **)error
    {
        BOOL failed;
        // Do some fancy stuff, if the operation fails, failed is true
        if (failed == YES) {
            if (error != NULL) {
                *error = [NSError errorWithDomain:@"your_domain" code:123 userInfo:nil];
            }
            return nil;
        }
    
        return [yourString autorelease];
    }
    
    // ...
    
    // Calling your method
    NSError *error = nil;
    [someObject generateString:someArray error:&error];
    

Обратите внимание на два ** и на то, что любой NSError var может быть NULL, а не nil (поэтому вы должны проверить это в теле метода).

person mplappert    schedule 11.01.2011
comment
Обратите внимание, что это должно быть *error = [NSError, а не &error = [NSError. Кроме того, вы все равно должны возвращать nil, даже если _3 _-- Я обычно использую два вложенных if для обработки такого рода случаев. Но Thinkos поражает лучших из нас - я предполагаю, что именно это и произошло здесь! - person Becca Royal-Gordon; 11.01.2011
comment
Спасибо за подсказку - * ошибка правильная, конечно -, - Исправлены обе проблемы в коде. - person mplappert; 12.01.2011

По умолчанию методы возвращают автозапуск NSString, и я бы рекомендовал использовать то же поведение. Если вам нужно изменить результирующую строку, вы можете использовать временные строки.

person Nickolay Olshevsky    schedule 11.01.2011
comment
Я не понимаю, что вы имеете в виду. По умолчанию методы возвращают автозапуск NSString. Где я могу увидеть это поведение по умолчанию? - person Chuck; 11.01.2011
comment
Спасибо, Николай, но я не совсем понимаю, что вы имеете в виду. Как это применимо к тому, о чем я прошу? - person BigBrother; 11.01.2011
comment
mplappert лучше описал эту идею) - person Nickolay Olshevsky; 11.01.2011