Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 161
На самом деле, смысла в описании различий синтаксиса нет никакого — понимание приходит через две недели работы, а начинать писать можно сразу же после прочтения статьи о языке в википедии.
А вот различия в семантике — особенно работа со счетчиком ссылок (assign/retain-init-copy, autorelease pool), категории и подстановки первое время серьезно бьют по мозгам.
Хотя уже через месяц вырабатываются практики использования всех этих возможностей для эффективного программирования. Правда, программисты на C# по инерции продолжают использовать категории в качестве партиальных классов.
А вот различия в семантике — особенно работа со счетчиком ссылок (assign/retain-init-copy, autorelease pool), категории и подстановки первое время серьезно бьют по мозгам.
Хотя уже через месяц вырабатываются практики использования всех этих возможностей для эффективного программирования. Правда, программисты на C# по инерции продолжают использовать категории в качестве партиальных классов.
*shoked*
когда-то начинал писать подобную серию статей для C# разработчиков, но после первого поста забросил — Objective-C для C# разработчиков
ваш подход «через шок» мне кажется интереснее.
<мысливслух>может тоже стоит возобновить и таки дописать этот предполагаемый цикл.</мысливслух>
ваш подход «через шок» мне кажется интереснее.
<мысливслух>может тоже стоит возобновить и таки дописать этот предполагаемый цикл.</мысливслух>
Казалось бы, что может быть интересного в сравнении синтаксисов двух языков… Но автору удалось удержать мое внимание до конца статьи и просить продолжить в том же духе. Наверное, если бы пришлось изучать Objective-C, статья не вызвала бы интереса, но для общего развития посмотреть в «чужой огород» было интересно. Спасибо. (сам пишу на java)
Когда я осваивал Objective-C, я был до смерти запуган подобными статьями. Теперь же могу сказать, что такие статьи — зло, а Obj-C я очень люблю.
Мобильная версия чуть промахивается, повторю — мне он тоже нравится, см последний пример
Просто новички (по себе сужу), больше внимания обращают не на объективные плюсы, а на часто саркастические пугающие комментарии к примерам и постам.
Лично я на комменты не обращаю внимание, тут фишка в другом. Не могу сказать, что я полиглот, но языков программирования знаю достаточно. Objective-C начал учить недели 3 назад по Kochan S. Programming in Objective-C 2.0 и сразу испугало объявление интерфейса:
Ну все-таки привык, когда "}" закрывает описание интерфейса/класса, а тут она закрывает только описание полей.
Сообщения, типа [fraction print] тоже убили… Сразу вспомнил статью про приставку «http://», когда разработчики стандарта говорили, что не подумали о возможной популярности протокола и может пользователи не набирали бы так много лишних символов (как-то так, не могу эту статью найти). Так и тут, выразительности ноль, зато есть много лишних элементов синтаксиса.
@interface Fraction: NSObject
{
int numerator;
int denominator;
}
-(void) print;
-(void) setNumerator: (int) n;
-(void) setDenominator: (int) d;
@end
Ну все-таки привык, когда "}" закрывает описание интерфейса/класса, а тут она закрывает только описание полей.
Сообщения, типа [fraction print] тоже убили… Сразу вспомнил статью про приставку «http://», когда разработчики стандарта говорили, что не подумали о возможной популярности протокола и может пользователи не набирали бы так много лишних символов (как-то так, не могу эту статью найти). Так и тут, выразительности ноль, зато есть много лишних элементов синтаксиса.
все эти «лишние» элементы синтаксиса отлично сам вставляет XCode
Но читает же программист? Или тоже XCode?
про какие лишние элементы синтаксиса вы говорите? @end? @interface? }?
Все-таки по современным меркам objective C — довольно уродливый язык. А без блоков он был бы еще и убогий.
Отсутствие обобщений довольно сильно угнетает, например. Зато встроенные примеси — это прекрасно, хотя по качеству они недалеко ушли от extension methods в C#.
Отсутствие обобщений довольно сильно угнетает, например. Зато встроенные примеси — это прекрасно, хотя по качеству они недалеко ушли от extension methods в C#.
Ну не знаю. С точки зрения синтаксиса — мне лично более симпатичен, чем знакомые С++ или JavaScript (хоть это и скриптовый язык, но мы же про синтаксис).
Некоторые считают, что extension methods — зло http://habrahabr.ru/blogs/net/122320/
Мне он тоже нравится, см последний пример
В плане схожего синтаксиса последнее время меня очень манит Objective-J – Cappuccino
Re: «В первом случае мы, конечно, получим NullPointerException и, возможно, увольнение. Во втором — в howManyHands будет возвращено 0. Это не 1, как мы ожидали, но хоть не уволили»
Это очень большой минус. Представим себе аналогичное поведение в Java: NullPointerException никогда не бросается. И бегай потом с дебаггером по всему коду и ищи почему он не работает.
Это очень большой минус. Представим себе аналогичное поведение в Java: NullPointerException никогда не бросается. И бегай потом с дебаггером по всему коду и ищи почему он не работает.
Это огромный плюс. Как Objective-C разработчик говорю — никаких проблем с отладкой.
Плюсы очевидны:
1 Мне не надо совать кучу проверок на nil и тд -> код меньше и проще
2 Если указатель был nil я знаю что я всегда получу (0, nil, NO и тд) и на этом строитятся много кода
3 Снижается шанс, что программа упадет если все таки проверка где-то забыта или nil появился там где его не ожидали
Плюсы очевидны:
1 Мне не надо совать кучу проверок на nil и тд -> код меньше и проще
2 Если указатель был nil я знаю что я всегда получу (0, nil, NO и тд) и на этом строитятся много кода
3 Снижается шанс, что программа упадет если все таки проверка где-то забыта или nil появился там где его не ожидали
Как Objective-C разработчик говорю — отсутствие NullPointerException — рассадник ошибок. Да, к этому привыкаеш, но тому кто это придумал я б гвоздь в голову забил.
А вы не путаете nil и NULL? nil — это полноценный объект, которому (сюрприз!) можно послать любое сообщение.
ой да какой рассадник ошибок? мне вот только помогает — например при отправке сообщения делегату не надо смотреть существует он или нет
3 года. Конечно в сообшениях в nil есть удобство при написании кода, но было бы лучше если бы была возможность отследить посылку сообшения в nil. Или если бы результатов сообшения от nil было какое то специфическое значение, а на 0.
)))
Победитель Game of The Year for iPad в этом году — моя игра Contre Jour. написана на objc конечно.
Не пропало желание опытом мериться?
Победитель Game of The Year for iPad в этом году — моя игра Contre Jour. написана на objc конечно.
Не пропало желание опытом мериться?
да. я прогер с опытом.
я это не считаю проблемой. Я считаю это полнейшым профтыком разработчиков языка.
посмотрите в инете видео contre jour. оцените сложность. и вам все станет понятно.
я это не считаю проблемой. Я считаю это полнейшым профтыком разработчиков языка.
посмотрите в инете видео contre jour. оцените сложность. и вам все станет понятно.
А какая разница, сколько я программирую? (3 года на objc если уж так интересно)
Мастерство не в месяцах измеряется. Я делаю крутые и сложные вещи.
Я знаю сколько времени у меня уходит на отлавливание багов, связаных с nil. У вас нет? Так может вы просто делаете примитивные проекты?
Мастерство не в месяцах измеряется. Я делаю крутые и сложные вещи.
Я знаю сколько времени у меня уходит на отлавливание багов, связаных с nil. У вас нет? Так может вы просто делаете примитивные проекты?
Сложность проекта и количество строк кода — величины весьма слабо связанные.
лол что? отловить сообщение нилу можно только переопределением obj_msgSend или навешиваним на нее проба в DTrace.
У вас какоето непреодолимое желание мерить все сантиметрами. Опыт в годах, сложность в строчках. Сложность в строчках не измеряется.
Дайте линк на какой-то свой проект и по описанию функционала будет видно сложный ли он.
method_exchangeImplementation — и к чему вы это??
Можно попробовать оверрайднуть obj_msgSend, но что тогда делать со всеми подключаемыми библиотеками, которые на такое поведение расчитывают?
Дайте линк на какой-то свой проект и по описанию функционала будет видно сложный ли он.
method_exchangeImplementation — и к чему вы это??
Можно попробовать оверрайднуть obj_msgSend, но что тогда делать со всеми подключаемыми библиотеками, которые на такое поведение расчитывают?
цитирую свой предыдущий комент (вы его читали?)
>но что тогда делать со всеми подключаемыми библиотеками,
>которые на такое поведение расчитывают?
>но что тогда делать со всеми подключаемыми библиотеками,
>которые на такое поведение расчитывают?
из того что я накопал я сделал вывод, что реплейснутый метод будет вызываться для всех библиотек.
а добавлять все классы каждой подключеной либы в блеклист… вы это действительно считаете приемлемым решением?
вообще для себя я нашел решение намного проще. следующие иОС проекты буду писать на моно. быстрее, удобнее и общяя код база для иОС, андроида и винфона.
а добавлять все классы каждой подключеной либы в блеклист… вы это действительно считаете приемлемым решением?
вообще для себя я нашел решение намного проще. следующие иОС проекты буду писать на моно. быстрее, удобнее и общяя код база для иОС, андроида и винфона.
mono уже врядли запретят — довольно популярные приложения на нем есть в сторе.
в WP7 не факт что плюсы добавят, да и пишу я под него уже прямо сейчас.
да и в плане скорости и удобства разработки C# всетаки намного привлекательнее чем C++. + следующий проект у меня возможно будет на Unity, а там опять C#.
Это не правило, конечно, но конкретно в моем случае mono выглядит очень хорошим решением.
в WP7 не факт что плюсы добавят, да и пишу я под него уже прямо сейчас.
да и в плане скорости и удобства разработки C# всетаки намного привлекательнее чем C++. + следующий проект у меня возможно будет на Unity, а там опять C#.
Это не правило, конечно, но конкретно в моем случае mono выглядит очень хорошим решением.
Лучшее решение этой проблемы это использование DTrace probe. Проб можно повесить на вызов obj_msgSend и настроить так чтобы он сообшал при вызове с нилом.
А до того я еще года 4 программировал на AS2, где аналогичное поведение null. И вздохнул с облегчением, когда из AS3 эту «фичу» убрали. И это несмотря на то, что AS2 вообще для меня был первым языком, на котором я работал.
Так что это явно не дело привычки.
Так что это явно не дело привычки.
Задача разработче состоит не втом, чтобы написать программу которая не падает, а в том, чтобы написать программу которая работает. Иногда такая особенность как посылка сообшения в nil может быть причиной ошибок.
Большинству пользователей не будет дела до того как она работает, если периодически она будет вываливаться.
Тоесть будет хуже если она будет неправильно реализовывать логику необходимую пользователю?) А если ваша программа падает/не падает, это не недостаток/преимущество языка, это мера вашей кривокукости)
Кто сказал, что она будет работать не правильно? Мой опыт говорит, что поведение nil больше плюс, чем минус, и статистикой (говорю только за себя) это подтверждается
Я сказал :) Возмем пример
— (long long)someCalculations;
ваш код расчитывает, что метод вернет или 0 или кактой значение, так же?
А что по вашему вернет метод при посылке сообшения в nil? Подумайте над этим)
Я не говорю, что сообшения в nil это вселенское зло, но это потенциальный источник проблем, а удобств он дает самую малось)
— (long long)someCalculations;
ваш код расчитывает, что метод вернет или 0 или кактой значение, так же?
А что по вашему вернет метод при посылке сообшения в nil? Подумайте над этим)
Я не говорю, что сообшения в nil это вселенское зло, но это потенциальный источник проблем, а удобств он дает самую малось)
извиняюсь на счет long long метода был не прав, уже пофиксили ) Раньше метод бы вернул не 0, а числовое представление селектора, но это было во времен 32 битного кокоа.
В 64 битном окружении проблем стало меньше) но опять же никто не отменял некоретного поведения основанного на nil, примет:
FireDetector *detector = [Detectors getDetector:kFireDetector];
//Предположим что по какой то ошибке в коде фабрика возврашает нам nil, какого поведение нашего кода в случае пожара?)
if ([detector isFire]) {
[self alarm];
}
FireDetector *detector = [Detectors getDetector:kFireDetector];
//Предположим что по какой то ошибке в коде фабрика возврашает нам nil, какого поведение нашего кода в случае пожара?)
if ([detector isFire]) {
[self alarm];
}
Вы просто со своей колокольни смотрите на это.
Я со своей колокольни iOS-разработчика смотрю точно так же.
Конечно, замечательно, что в язык встроен патерн null object, нередко это бывает очень полезно. Но я бы все-таки хотел, чтобы реализация его была явной, например в виде [SomeObject nilInstance]
Единственное, что действительно приносит определенную пользу — это не падающий [nil release]
Конечно, замечательно, что в язык встроен патерн null object, нередко это бывает очень полезно. Но я бы все-таки хотел, чтобы реализация его была явной, например в виде [SomeObject nilInstance]
Единственное, что действительно приносит определенную пользу — это не падающий [nil release]
Я не гуру, конечно, но почему рекомендуют делать так, аргументируя, что типа так безопаснее?
[name release];
name = nil;
Дело в том, что после [name release] в переменной name остается адрес уже мертвого объекта. Любое обращение к этому объекту выдает SIG_BAD_ACCESS, который потом долго придется отлавливать с помощью NSZombie и прочих эзотерических практик.
Да, что бы обезопасить себя.
Яркий пример касается uiviewcontrollera
Не гарантируется, что метод viewDidUnload будет вызван, а в нем рекомендуется освобождають ui шные переменные. В то же время, dealloc точно будет вызван. Что бы не возникла ситуация с утечкой памяти релизят и в методе viewdidunload и в dealloc. При этом если зарелизиться в viewdidload и переменной будет присвоенно nil, то в dealloc еще один realese к нилу пройдет незаметно.
Яркий пример касается uiviewcontrollera
Не гарантируется, что метод viewDidUnload будет вызван, а в нем рекомендуется освобождають ui шные переменные. В то же время, dealloc точно будет вызван. Что бы не возникла ситуация с утечкой памяти релизят и в методе viewdidunload и в dealloc. При этом если зарелизиться в viewdidload и переменной будет присвоенно nil, то в dealloc еще один realese к нилу пройдет незаметно.
Вы о чем? viewDidUnload не вызывается при удалении. Для освобождения ресурсов при удалении объекта только dealloc.
viewDidUnload метод для реакции на некоторые особые ситуации. Например, сообщение low memory warning. В этом методе рекомендуется освободить
все IB объекты и все, что потом легко восстановить в методе viewDidLoad (если вызван viewDidUnload то точно будет вызван повторно viewDidLoad, если объект раньше не удалят).
Пример с low memory warning.
Есть 2 viewController: А и В, мы используем navigationController для навигации между ними. У нас сначало был открыт А, в нем мы нажали что-либо и открылся В. Тоесть стек навигации: А->B.
Приходит сообщение low memory warning, при этом у A вызывается viewDidUnload, но только у А, потому что он не на экране и его объекты интерфейса можно освободить (у того контроллера, который находится на экране
viewDidUnload не вызывается, иначе юзер получит пустую форму). Дальше юзер поработал в В и нажал кнопку назад чтобы вернуться в A, при этом в A будет повторно вызван viewDidLoad чтобы восстановить объекты интерфейса и тд освобожденные в viewDidUnload.
У B, при возвращении к А, вызовется только dealloc (не в коеv случае не viewDidUnload)
viewDidUnload метод для реакции на некоторые особые ситуации. Например, сообщение low memory warning. В этом методе рекомендуется освободить
все IB объекты и все, что потом легко восстановить в методе viewDidLoad (если вызван viewDidUnload то точно будет вызван повторно viewDidLoad, если объект раньше не удалят).
Пример с low memory warning.
Есть 2 viewController: А и В, мы используем navigationController для навигации между ними. У нас сначало был открыт А, в нем мы нажали что-либо и открылся В. Тоесть стек навигации: А->B.
Приходит сообщение low memory warning, при этом у A вызывается viewDidUnload, но только у А, потому что он не на экране и его объекты интерфейса можно освободить (у того контроллера, который находится на экране
viewDidUnload не вызывается, иначе юзер получит пустую форму). Дальше юзер поработал в В и нажал кнопку назад чтобы вернуться в A, при этом в A будет повторно вызван viewDidLoad чтобы восстановить объекты интерфейса и тд освобожденные в viewDidUnload.
У B, при возвращении к А, вызовется только dealloc (не в коеv случае не viewDidUnload)
Такое есть:
Пример использования:
[NSNull null];Пример использования:
NSArray *arr1=[NSArray arrayWithObject:nil]; //исключение
NSArray *arr2=[NSArray arrayWithObject:[NSNull null]]; //без ошибокНо проблема [(NSObject *)nil retain] остается.
А какая проблема? Мб просто я не понял о чем вы. nil можно ретайнить и релизить сколько угодно, никаких ошибок и утечек не будет.
Допустим, у меня есть массив, который я получаю в функцию и дальше считаю количество элементов. В случае, если мне в функцию передадут nil и я забуду сделать проверку — у меня будет каждый раз отрабатывать так, как будто мне передали массив из 0 элементов.
В Objective-C это нормально. Как я говорил выше на этом строится много логики. В принципе, достаточно логично: массив = nil -> в нем просто 0 элементов
Это у вас на этом строится много логики. Вы же не думаете, что ваш подход — самый правильный и стройный?
Кроме того, nil и масссив из 0 элементов это разные вещи. Например, массив из 0 элементов вернет respondToSelector:@selector(objectAtIndex:) YES, а nil вернет NO.
Кроме того, nil и масссив из 0 элементов это разные вещи. Например, массив из 0 элементов вернет respondToSelector:@selector(objectAtIndex:) YES, а nil вернет NO.
Не только у меня. В том числе и примеры apple. Это стиль Objective-C.
Может я не правильно выразился. Я имел в виду следующее, в многих случаях это очень удобно, например, зачем писать так (как сделали бы по привычке, люди писавшие, на том же C):
Если проще использовать следующее (это вы увидите везде, и в примерах apple, и в принципе в примерах по Objective-C)
-(void)dealloc
{
if(obj1!=nil)
[obj1 release];
if(obj2!=nil)
[obj2 release];
[super dealloc];
}
Если проще использовать следующее (это вы увидите везде, и в примерах apple, и в принципе в примерах по Objective-C)
-(void)dealloc
{
[obj1 release]; //если obj1==nil, то ничего не произойдет
[obj2 release]; //если obj1==nil, то ничего не произойдет
[super dealloc];
}
Эх, живой явный последователь smalltalk
Именованные параметры в методах мне даже нравятся (хотя я плевался, когда впервые столкнулся с ними в ABAP :).
Категории напоминают JavaScript.
Но вот счётчики ссылок для меня пока за гранью добра и зла :(
Категории напоминают JavaScript.
Но вот счётчики ссылок для меня пока за гранью добра и зла :(
Мне наоборот нравятся счетчики ссылок)) В последних версия Xcode есть компилятор со сборщиком мусора, так что если вас пугают счетчики ссылок, то просто используйте его (apple сам его рекомендует, по крайней мере для начала)
сборщик мусора существует уже очень давно, а точнее с версии Мака 10.5, а если вы имеете ввиду ARC, то это не сборщик мусора, а статический умный «подставлятель» release/retain ов. Что просто декорирует а не убирает это поведение. Для iOS сборщика мусора не будет скорее всего, и я склонен к мысли что это хорошо, а не плохо. Да и компилятор к икскоду имеет не совсем прямое отношение и поддержка ARC появилась в LLVM3 достаточно давно, помоему более чем пол года назад.
Для iOS сборщика мусора, вроде бы, нет.
И Эплл, похоже, опять передумал, и рекомендует всем переходить с GC на ARC.
И Эплл, похоже, опять передумал, и рекомендует всем переходить с GC на ARC.
Счетчик ссылок — это как в поговорке «Сила есть – ума не надо», только наоборот.
С удовольствием прочитал бы продолжение. Про подсчет ссылок, сборку мусора, свойства, рефлексию и т.д. И еще — про внутреннее устройство системы диспетчеризации сообщений.
Маленькое замечания по селекторам
Селектор это не совсем так
Это скорей так
Т.е. withValue и asOptional это Необязательные подсказки и их можно не указывать, вызвав метод так
или
Селектор это не совсем так
addFeature:withValue:asOptional:Это скорей так
addFeature:::Т.е. withValue и asOptional это Необязательные подсказки и их можно не указывать, вызвав метод так
[self addFeature :@"Foo" :@"bar" :YES]или
SEL selector = @selector(addFeature:::)
Не стоит начинать название метода с «get»:
Хотя это и не обязательно, но Apple рекомендует это тут
Use “get” only for methods that return objects and values indirectly. You should use this form for methods only when multiple items need to be returned.
-(Feature*) getFeature:(NSString*)name;Хотя это и не обязательно, но Apple рекомендует это тут
Use “get” only for methods that return objects and values indirectly. You should use this form for methods only when multiple items need to be returned.
- (void)getLineDash:(float *)pattern count:(int *)count phase:(float *)phase;
Напишите еще.
А современный компилятор Objective C для иос поддерживает C++? Если да, то на каком уровне? Можно ли писать только на с++, вообще не используя синтаксис Objective C? А то этот язык уж очень опасен своей работой с памятью, кучей с сложностей с подсчетом ссылок, в то время как на с++ с его деструктуроми и перегрузкой операторов подсчет ссылок делается практически прозрачным и автоматическим.
Objective-C гораздо проше чем C++. Писать использую C++ можно, но для работы с какими то системными либами (GUI, FS, etc) придется юзать Objective-C
В Xcode ≥ 4.2 в коробке идёт Clang 3.0, соответственно его фичи смотрите здесь: clang.llvm.org/cxx_status.html. Только замечу, что C++11 доступен только в iOS ≥ 5.0.
Можно ли писать только на с++, вообще не используя синтаксис Objective C
Можно. Хотя, конечно бОльшая часть API в iOS — на Objective-C (оставшаяся часть — на чиcтом C), и использовать его всё равно придется.
А то этот язык уж очень опасен своей работой с памятью, кучей с сложностей с подсчетом ссылок, в то время как на с++ с его деструктуроми и перегрузкой операторов подсчет ссылок делается практически прозрачным и автоматическим.
Это вы зря. Мне после C++ было наоборот намного приятней работать с Objective-C. А после недавнего введения ARC (Automatic Reference Counting) вообще просто сказка.
Можно ли писать только на с++, вообще не используя синтаксис Objective C
Можно. Хотя, конечно бОльшая часть API в iOS — на Objective-C (оставшаяся часть — на чиcтом C), и использовать его всё равно придется.
А то этот язык уж очень опасен своей работой с памятью, кучей с сложностей с подсчетом ссылок, в то время как на с++ с его деструктуроми и перегрузкой операторов подсчет ссылок делается практически прозрачным и автоматическим.
Это вы зря. Мне после C++ было наоборот намного приятней работать с Objective-C. А после недавнего введения ARC (Automatic Reference Counting) вообще просто сказка.
Правильная ссылка: clang.llvm.org/cxx_status.html
Ну, у меня нет опыта с Objective C. Я просто как то на синтаксис взглянул и ужаснулся, что там будет твориться, если случился Exception. Это ж в каждой функции надо блок finally писать. Код по сравнению с с++ получается просто нечитаемым. Впрочем, может это впечатление у меня с непривычки. Но пока я бы предпочел первым делом сделать с++ обертки для всех системных библиотек и забыть про эту нахлобучку на с.
Exception в Objective-C(без GC) практически не применяються, только для каких то критических событий после который программа уже не может продолжать свое выполнение.
А код на Objective-C на порядок читабельнее кода на большинстве других языков, особеннос по сравнению с С++ :)
А код на Objective-C на порядок читабельнее кода на большинстве других языков, особеннос по сравнению с С++ :)
Наверное, потому и не используются, что они там прилеплены для галочки. Он вообще весь какой то внутренне противоречивый, на мой взгляд. Я не верю, что код, который делает одно и то же на с++ будет выглядеть сложнее, просто потому, что у с++ возможностей больше, хотя бы деструкторы. На Objective C читабельнее могут быть только очень простые программки. Чуть только что посложнее, и всё, жопа, память потеряна, обработка ошибок из миллиона строк.
Повторяю, это всё имхо, впечатление возникло от первого знакомства с синтаксисом.
Повторяю, это всё имхо, впечатление возникло от первого знакомства с синтаксисом.
Ну так в этом и проблема, познакомтись с ним поближе и все пройдет) А код на С++ будет выглядеть сложнее как раз таки потому что в С++ больше возможностей. Весь Objective-C описыватеся очень небольшим набором концепций, в то время как в С++ разных тонкостей гораздо больше. А если говорить про имхо, то лично для меня С++ выглядит как уродливый набор разного рода фич который делали с мотивацией вида: «А не добавить ли на фичу <названиефичи>», а не затем что она действительно нужна. Помоему один из отцов основателей нашей индустрии говорил, что формальная граматика хорошого языка должна занимать не больше пары страниц, Objective-C думаю сможет уложиться в пару страница, а С++ точно нет :)
Может быть. :) Я просто хорошо знаю с++ и он мне кажется очень логичным и целостным, а Objective C нет, и первое знакомство повергло меня в ужас. А у вас обратная ситуация. Может, я не успел ухватить общую картину. Будем надеяться.
Да он вам понравиться, я знаю двух С++ разработчиков которые по началу тоже плевались на Objective-C, а сейчас уже во всю на не нём под iOS пишут, причем вполне успешно.
Надеюсь. Слава Джобсу, переход на Objective C облегчен поддержкой с++. То есть использовать именно Objective C можно именно там, где это действительно удобно. Такие случаи, конечно, есть.
Если вы планируете, что в будушем ваш проект будут поддерживать другие люди, то я крайне не рекомендую использовать С++ в нем, если это конечно не игра с каким то кросплатформенным движком. Это позволит вам избежать проклятий в свою сторону от будуших разрабов, так как поддержка кода на смеси Objective-C и C++ то еше удовольствие :)
Все языки одинаковы. API и project environment разные. И не пугайтесь Вы alloc release. В С никто не забывает malloc free, а если и забудет — никто не умрет.
Для говнокодеров, если руки из жопы — то уже ничего не поможет, кроме gc.
Вы забываете, что это не компьютер и общее количество памяти, а так же память на одну программу в iOS сильно ограничена. Поэтому «а если и забудет — никто не умрет» тут не подходит. Да, мелкие утечки я согласен, в принципе не страшно. А если вы забыли удалить какой-либо крупный объект? С учетом того, что приложения обычно юзеры не закрывают, а просто сворачивают и они так и висят месяцами. Рано или позно юзер развернет приложение и получит креш, если мы забыли удалить что-то крупное.
Да уж, у Objective C растёт не только популярность, но и возраст — скоро 30 лет ему исполнится. Неужели платформы Apple нативно не поддерживают более современные языки?
Может, потому, что Apple всегда особенная, и по особенному смотрит на вещи? :)
Эм, а подскажите мне язык, сочитаюший в себе высокую скорость выполнения, динамизм и простоту уровня Objective-C?)
С++?
простоту? серьезно? по вашему С++ простой язык? И в любом коде на С++ легко разобраться? Тем более С++ не очень хорошо подходит для GUI фреймворков.
та и с динамизмом у С++ не очень.
Я не буду об этом спорить, соглашусь только, что Objective C выглядит (и, похоже, является) компромиссом. В результате при напмсании программ на нем, даже в случае хорошего фреймворка, надо быть чрезвычайно аккуратным, потому что компилятор ни хрена не проверяет и многие конструкции языка плохо взаимодействуют друг с другом.
В с++ все гораздо лучше. Там можно написать фреймворк, которым легко и безопасно пользоваться. В том числе и гуевый.
В с++ все гораздо лучше. Там можно написать фреймворк, которым легко и безопасно пользоваться. В том числе и гуевый.
Другое дело, что такого фреймворка, может и не написано, но это как раз вина Apple.
да все там хорошо с компилятором, все что нужно в рамках языка и идеологии он проверяет.
вы просто не разобравшись в новом, начинаете защищать знакомое.
я не фанат объектно-ориентированной идеологии разработки (мне ближе категории которыми оперирует процессор а не «очеловеченные» абстракции), но что касается реализации ООП в С++ — то это, тот еще костыль. Почитайте про смалталк хотя бы.
вы просто не разобравшись в новом, начинаете защищать знакомое.
я не фанат объектно-ориентированной идеологии разработки (мне ближе категории которыми оперирует процессор а не «очеловеченные» абстракции), но что касается реализации ООП в С++ — то это, тот еще костыль. Почитайте про смалталк хотя бы.
Не будем разводить холивар, я действительно очень поверхностно знаком с objective c.
Понятно, что и с++ и objective c оба являются надстройкой над с. Только при этом, на мой взгляд, с++ в этом отношении более качественный. Потому что мне ближе именно Ооп подход, и возможность сосредоточения на реальной задаче, а не на борьбе со счетчиками ссылок. В с++ есть деструкторы, в Java хоть сборщик мусора, а в objective c всё вручную. Не знаю, как вам, а мне эта рутина претит. Особенно учитывая, что в других языках с этим всё в порядке.
То есть, проблема даже не в синтаксисе аля смолтолк, а в том, что привнесенные объекты в обжектив с не образуют полную инфраструктуру, как объекты в с++
Понятно, что и с++ и objective c оба являются надстройкой над с. Только при этом, на мой взгляд, с++ в этом отношении более качественный. Потому что мне ближе именно Ооп подход, и возможность сосредоточения на реальной задаче, а не на борьбе со счетчиками ссылок. В с++ есть деструкторы, в Java хоть сборщик мусора, а в objective c всё вручную. Не знаю, как вам, а мне эта рутина претит. Особенно учитывая, что в других языках с этим всё в порядке.
То есть, проблема даже не в синтаксисе аля смолтолк, а в том, что привнесенные объекты в обжектив с не образуют полную инфраструктуру, как объекты в с++
Вы не разобрались и делаете поспешные выводы, на основе слухов и домыслов.
В objectivec используется GC (например, в маке).
Что касатеся ифона, там собрщик мусора — гусенечный привод для телеги, поэтому в первых версиях ввели ручное управления счетчиками.
Но сейчас с появлением ARC (полгода как уже), об этом можно забыть и писать как для больших платформ, все будет учтено автоматом.
В результате стало проще писать и производительность кода осталось на высоком уровне… да и утечек теперь будет меньше ибо все учитывае автомат.
В objectivec используется GC (например, в маке).
Что касатеся ифона, там собрщик мусора — гусенечный привод для телеги, поэтому в первых версиях ввели ручное управления счетчиками.
Но сейчас с появлением ARC (полгода как уже), об этом можно забыть и писать как для больших платформ, все будет учтено автоматом.
В результате стало проще писать и производительность кода осталось на высоком уровне… да и утечек теперь будет меньше ибо все учитывае автомат.
Чем dealloc не деструктор? Какие проблемы с памятью, вы о чем? Я перешел на Obj-C с .Net, да, первое время было тяжко и не превычно без GC. Но если придерживаться пары простых правил, то никаких утечек борьбы со счетчиками ссылок и в помине нет. К тому же в XCode встроен отличный статический анализатор, который большинство тривиальных утечек памяти легко детектит.
Можно уточнить — какие, например? Для большинства и Lisp все еще язык из будущего.
Любые популярные на данный момент у разработчиков и активно развиваемые. При этом популярность Objective C несколько искусственна, ибо программисты вынужденно начинают писать на нём, так как видят в платформах Apple золотую жилу.
Может после смерти Джобса, Apple повернётся лицом к разработчикам.
Может после смерти Джобса, Apple повернётся лицом к разработчикам.
Не лезете в чужой моностырь, со своими уставами.
ObjectiveC — это основной столб мак платформы. На его базе построенно все семейство OS X и все программы под мак написаны на нем с использованием апловских фреймворков.
Не удивительно, что его (язык и фреймворки) перенесли на ифон, как перенесли и наработки из OS X в iOS.
Тоесть разработчику под мак, что бы начать писать под ифон, необходим самый минимум телодвижений.
В двух словах, все сделали в рамках устоявшихся традиций и экосистемы.
А теперь на хорошую возможность заработать, привалила куча нищебродов и начинает рассказывать что кошерно, а что нет.
ObjectiveC — это основной столб мак платформы. На его базе построенно все семейство OS X и все программы под мак написаны на нем с использованием апловских фреймворков.
Не удивительно, что его (язык и фреймворки) перенесли на ифон, как перенесли и наработки из OS X в iOS.
Тоесть разработчику под мак, что бы начать писать под ифон, необходим самый минимум телодвижений.
В двух словах, все сделали в рамках устоявшихся традиций и экосистемы.
А теперь на хорошую возможность заработать, привалила куча нищебродов и начинает рассказывать что кошерно, а что нет.
Я шокируюсь при одном только виде синтаксиса Objective-C. Чтобы настолько изуродовать старый добрый Си надо было постараться.
Хорошо, что я не один такой. А то я был в таком шоке, что вообще засомневался, как можно на таком кошмаре написать неплохую иос. Objective C выглядит как сиюминутная заплатка, которую в своё время неосторожно ввели, а потом просто не оставалось сил от неё избавиться. Вот все до сих пор и мучаются. Хорошо хоть с++ все таки поддерживается.
Я тоже шокировался синтаксису С после паскаля, в лихих 90-ых.
Но ничего, мне это не помешало статить системным программистом.
Но ничего, мне это не помешало статить системным программистом.
Постараюсь в следующей статье переубедить.
Синтаксис не такой уж ужасный, просто непривычный. Зато сами возможности языка просто потрясающие. Чего только стоит отправка сообщений вместо вызова методов!
Синтаксис только кажется страшным, на самом деле, если не городить монтруозных вложенных конструкций, он очень легко читается. XCode отличная IDE, она прекрассно дописывает код, и сама расставляет скобочки там где это нужно. Просто не превычно по началу, но потом привыкаешь, и все становится намного лучше.
Вижу надо продолжать. Почитал комментарии, пока план такой: философия языка (С, минимализм и вера в человека), id и его отличия от void* и Object, подсчет ссылок (почему это просто и что не так alloc/new )
Рекомендую практикующим Obj-C программистам к ознакомлению: BlocksKit. И стиль написания и возможности из коробки помогают писать интересные вещи, для которых раньше требовались обходные пути. Например заменить делегаты блоками и не писать в UIAlertViewDelegate определение, какая же это мессага закрылась сейчас.
возможно, вы сможете написать об этом статью? Чтобы таким новичкам, как я, легче было проникнуться ;)
Откройте документацию на сайте, там достаточно примеров к большинству методов.
если вы об этом, то всё-же хорошая статья с примером «документации на сайте» не помешает :)
Хорошая статья. Сам джавист и тоже в свободное время начал почитывать про objC. Многое непривычно, но этого и стоило ожидать. У меня например есть коллега, который с java на хаскель перешел. И ниче — доволен))
Вы будете удивлены, но большинство полезных концепций реализовано в Java в том или ином виде.
> Посылаем, а не вызываем, сообщения, а не методы
В Java есть класс Proxy, позволяющий генерить обертки для объектов. Кроме того, концепция давно знакома любителям AOP и Spring. Посылка же сообщений чаще всего предполагает именно асинхронный обмен данными, что в Java достигается помощи популярной ныне модели Actors. В данном же случае эта операция имеет свойства именно вызова функции (один тред, стек, блокирующий вызов). Так что можно сильно спорить по поводу корректности терминологии.
> Серьезный шок: любой может испортить мой класс, а не только я
Производные от Java языки типа Groovy, Xtend, Kotlin имеют похожую концепцию расширений (class-extensions). Причем сам класс никак не «портится», это только алиас функции, которая работает над классом в текущем namespace.
> Совсем шокирующее: неинициализированные ссылки не портят почти ничего
Оч. и оч. спорное «улучшение». Это нормально для «скриптовых» языков с нестрогим контролем типов, типа Groovy. В производных языках (Scala, Kotlin, Fantom) взяли концепцию nullable types от C#. Автоматический контроль null програмистам Java должен быть знаком от J2EE/EL и JavaFX Script.
Вот что действительно шокирует, так это синтаксис Objective-C, непохожий ни на один из привычных языков. Но это дело привычки.
> Посылаем, а не вызываем, сообщения, а не методы
В Java есть класс Proxy, позволяющий генерить обертки для объектов. Кроме того, концепция давно знакома любителям AOP и Spring. Посылка же сообщений чаще всего предполагает именно асинхронный обмен данными, что в Java достигается помощи популярной ныне модели Actors. В данном же случае эта операция имеет свойства именно вызова функции (один тред, стек, блокирующий вызов). Так что можно сильно спорить по поводу корректности терминологии.
> Серьезный шок: любой может испортить мой класс, а не только я
Производные от Java языки типа Groovy, Xtend, Kotlin имеют похожую концепцию расширений (class-extensions). Причем сам класс никак не «портится», это только алиас функции, которая работает над классом в текущем namespace.
> Совсем шокирующее: неинициализированные ссылки не портят почти ничего
Оч. и оч. спорное «улучшение». Это нормально для «скриптовых» языков с нестрогим контролем типов, типа Groovy. В производных языках (Scala, Kotlin, Fantom) взяли концепцию nullable types от C#. Автоматический контроль null програмистам Java должен быть знаком от J2EE/EL и JavaFX Script.
Вот что действительно шокирует, так это синтаксис Objective-C, непохожий ни на один из привычных языков. Но это дело привычки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шокирующий Objective-C для Java программистов