Первые шаги[iPhone]

Здравствуйте!

Нужен ваш совет как лучше освоить SDK iPhone и XCode:
С синтаксисом Objective-C уже ознакомился, правда есть небольшие фейлы с семантикой но это нормально поскольку Objective-C только пару дней как разбираться начал, а сегодня только попробовал его на деле. И теперь пытаюсь раскурить фреймворк iPhone(а) и не знаю с какого боку к нему подойти.

1. Может подскажите серию  туториалов по этому поводу или нечто подобное с чего вы начинали знакомство с XCode и iPhone SDK?

2. И мучает такой вопрос: какие правила и ограничения есть на использование именно C++?(За сегодня не успел попробовать, а на грабли наступать не очень хочется)

ЗЫ Спасибо за понимание и помощь

[ПРАВКА:]
Добавлено:
Решение проблемы в посте #27

shcoder
> 2. И мучает такой вопрос: какие правила и ограничения есть на использование
> именно C++?(За сегодня не успел попробовать, а на грабли наступать не очень
> хочется)

Тут не скажу.
Но если хочется писать именно на Си++, то можно воспользоваться Airplay SDK, я пишу и прям счастлив, что у меня никто мой любимый Си++ не отбирает и любимую Visual Studio тоже. :)

shcoder
> И мучает такой вопрос: какие правила и ограничения есть на использование именно
> C++?(За сегодня не успел попробовать, а на грабли наступать не очень хочется)
нету никаких ограничений. переименовываешь фаел в mm и пишешь на с++. с кокоа и прочим отстоем конечно надо на обжектив с но там этого кода кот наплакал. создаешь пустой огл проект и там вообщемто всё есть, вставляешь свою функцию отрисовки и в бой

shcoder
Unity, UDK - паблиш в iOS. По-моему, наиболее эффективный старт.

decreat
+400/1500 и +100 долларов США соответственно.

ffinder
С Unity да, как-то погорячился, там недетские ценники. Но UDK тут не при чем, из него паблиш бесплатный (да и сам конструктор). Сотня за девелоперскую лицензию, которую все равно покупать, даже если среда разработки Notepad.

1. Доки на сайте эпла
2. Нет никаких ограничений

Executor
> я пишу и прям счастлив, что у меня никто мой любимый Си++ не отбирает
Его никто и в XCode не отберет ;)

Executor
> и любимую Visual Studio тоже. :)
а с этим сложнее. Можно писать кроссплатформенный код...

1. xCode достаточно удобный и простой, да и обджектив как по мне весьма прост и удобен (сам с С++ начинал). Гугл по прежнему красафчеГ.
2. Можно, но не советую. Не настолько большая разница между обджем и С++ что бы извращаться.

П.С. Airplay как вариант, но 30 дней триала.

NVS
> xCode достаточно удобный и простой
И кандидат на худшую IDE 1000-летия. Особенно 3-ий. Сode sense работает только в зависимости от фазы луны, средства для рефакторинга минамальные, только для obj-c, и не всегда работают. Разобраться в адекватном конфиге проекта в 3-ем можно только крепко накурившись, некоторые решения в дизайне принимались явно под тем самым крепким накуром. 4-ка чуть получше, но пока preview и умеет по прежнему мало и плохо. Отдельную благодарности соит выразить instruments, которые в ряде случаев жрут столько памяти, что iOS убивает анализируемое приложение. Правда выбора яблочники тоже предоставлять не хотят.

NVS
> Не настолько большая разница между обджем и С++
Если производительность не критична, то да, можно пользоваться ObjC. А вот если критична, то извините...

NVS
Airplay под iOS бесплатный

crsib
Не испытываю подобных трудностей.

evirus
дамс... забыл. Сижу на инди.

NVS
> Не испытываю подобных трудностей.
Ну как бы все по потребностям. В ряде случаев и блокнота хватит. А некоторые все в vi делают. На небольших проектах можно и забить в принципе на то, что code sense не context sensitive (причем иногда даже в obj-c не context sensitive, тут уж как повезет), и что нет даже минимальных средств для рефакторинга. Весь вопрос в масштабах и требованиях.

crsib
офтоп:
> Если производительность не критична, то да, можно пользоваться ObjC. А вот если критична, то извините...
Есть какие-нибудь материалы или тесты, которые это доказывают? Не ради холивара спрашиваю, просто на самом деле интересно насколько Objective-C медленее C++.

пишу на обжектив-си в X-Code.... такие эти макосы деревянные просто ппц... хотя пишется нормально но по гламурности вижстудийного сишарпа скучаю =)

NightBlaze
> Есть какие-нибудь материалы или тесты, которые это доказывают?
Есть всякие веселые статейки. Особенно все любят NSArray (CFArray), ибо он реально странненький, как 7-ми долларовая купюра. http://memo.tv/nsarray_vs_c_array_performance_comparison
http://ridiculousfish.com/blog/archives/2005/12/23/array/#fish_made_a_mess

Но основная проблема состоит в том, что в Obj-C все "методы" (селекторы, если быть точным) являются "вирутальными". Все посылки сообщений превращаются компилятором в вызов objc_msgsend, который осуществляет попытку вызвать непосредственно метод. Любопытная рыбка утверждает, что все было бы на 30% лучше, если бы не динамическая линковка, однако проблему это не особо снимает, так как случайно получилось, что у значительной часть "методов" в Foundation/UIKit/choose whatever you want cтоимость вызова ощутимо выше, чем время выполнения. Сравнение вызова виртуальной функции в С++ и посылки сообщения в Obj-C на x86, на фруктах (imp cached можно считать вызовом С функции). Как видим, objc_msgsend стоит дороже, и иногда значительно, чем многострадальный вызов виртуальной функции в С++, который мусолился в over9000 тем на этом форуме. Что делает посылку сообщений в obj-c еще менее применимой в tight loop'ах. Более того, objс_msgsend будет генерироваться и при использовании пропертей. И, в отличии от C++, в Obj-c нельзя сделать вызов невиртуальным (не считая imp кэширования, но оно ппц страшное и используется если уж совсем сильно приперло) и уж тем более что-либо заинлайнить.

Помимо всего этого есть еще личный опыт общения с акулой/instruments. Использование Obj-c всегда радостно светится в топах профайлера, "автоматическое" кэширование на моей памяти никогда толком не работало. Добавь к этому чудо контейнеры из foundation и гениальную механику управления памятью - и у сразу отпадет вопрос, почему Obj-C не для perf critical кода