>Здесь же сразу идем на вкладку “Build Settings” и ставим “Objective-C Automatic Reference Counting” в “No”, т.к. в iOS нет сборщика мусора.

Что? Это не сборщик мусора, это совсем другое и оно прекрасно работает на iOS! Используйте!

А зачем поддерживать старые девайсы?

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

Все это умеет делать itunes

Ну так для другого разрешения и нужен новый UI, а не оптимизированный старый.

Софт можно и покупать, стоит он не дорого, а остальные фичи не нужны никому кроме гиков. :)

А зачем вам прямой доступ к файловой системе?

Думаю midday завидует качеству приложения под ios. Под андроид качественных приложений практически нет.

Лучшее решение этой проблемы это использование DTrace probe. Проб можно повесить на вызов obj_msgSend и настроить так чтобы он сообшал при вызове с нилом.

лол что? отловить сообщение нилу можно только переопределением obj_msgSend или навешиваним на нее проба в DTrace.

про какие лишние элементы синтаксиса вы говорите? @end? @interface? }?

тада, я что то не очень удачный пример привел, но в целом это показывает возможные последствия от нила

В 64 битном окружении проблем стало меньше) но опять же никто не отменял некоретного поведения основанного на nil, примет:

FireDetector *detector = [Detectors getDetector:kFireDetector];

//Предположим что по какой то ошибке в коде фабрика возврашает нам nil, какого поведение нашего кода в случае пожара?)

if ([detector isFire]) {
[self alarm];
}

извиняюсь на счет long long метода был не прав, уже пофиксили ) Раньше метод бы вернул не 0, а числовое представление селектора, но это было во времен 32 битного кокоа.

Я сказал :) Возмем пример

— (long long)someCalculations;

ваш код расчитывает, что метод вернет или 0 или кактой значение, так же?
А что по вашему вернет метод при посылке сообшения в nil? Подумайте над этим)

Я не говорю, что сообшения в nil это вселенское зло, но это потенциальный источник проблем, а удобств он дает самую малось)

Если вы планируете, что в будушем ваш проект будут поддерживать другие люди, то я крайне не рекомендую использовать С++ в нем, если это конечно не игра с каким то кросплатформенным движком. Это позволит вам избежать проклятий в свою сторону от будуших разрабов, так как поддержка кода на смеси Objective-C и C++ то еше удовольствие :)

Да он вам понравиться, я знаю двух С++ разработчиков которые по началу тоже плевались на Objective-C, а сейчас уже во всю на не нём под iOS пишут, причем вполне успешно.

Ну так в этом и проблема, познакомтись с ним поближе и все пройдет) А код на С++ будет выглядеть сложнее как раз таки потому что в С++ больше возможностей. Весь Objective-C описыватеся очень небольшим набором концепций, в то время как в С++ разных тонкостей гораздо больше. А если говорить про имхо, то лично для меня С++ выглядит как уродливый набор разного рода фич который делали с мотивацией вида: «А не добавить ли на фичу <названиефичи>», а не затем что она действительно нужна. Помоему один из отцов основателей нашей индустрии говорил, что формальная граматика хорошого языка должна занимать не больше пары страниц, Objective-C думаю сможет уложиться в пару страница, а С++ точно нет :)

та и с динамизмом у С++ не очень.