Возьмите любую реальную задачу и дальше уже сами увидите, где что надо лепить. Все же зависит от задачи, которую будете пользовать.
Возьмите и реплицируйте приложение из стора какое-нить, сразу же встанет куча вопросов из этой области.
Например, журнал по скелету из хмл с видео вставками, чтение пдф, редактирование изображений, звука, видео, можно то же самое, но в реалтайме, а потом еще то же самое, но с предварительным кешированием чанков в памяти, ну уже сверху плеер какого-нить страшненького стриминг радио. Создайте парочку красивых кастомных элементов уи, которые базируюцца не на изображениях, легко изменяюцца в размерах и классно ощущают себя при ресайзинге. Тысячи их.
>Связан, когда проишодит посыл мессаджа, рантайм вначале смотрит в кеш не отрезолвлен ли адрес метода уже. Это и называется IMP кешем, и оно выделено крансым на листинге на который я ссылался.
Этот механизм являецца частью месседжинга и имп-кешем не называецца. Собсно, об этом я и говорил изначально, говоря, что «objc_msgsend — это то, что скрываецца под синтаксисом вызова любого метода и не связан с IMP-cache никак.»
Внутреннее кеширование есть, но его проверить сложно, т.к. рантайм сам занимаецца резолвом и предсказать, когда лезет в кэш, а когда и без кэша хорошо живет невозможно, посему и замерить невозможно. Именно поэтому, имп — кеш — то, что сказал я, а внутреннее кэширование замеряют по станадртному месседжингу.
Вот имп-кеш по версии Эша:}
— (void)_stubMethod {}
>То о чем ты говоришь это вызов метода в обход кеша, со всеми вытекающими последствиями(типа какой то хакер поменял класс в рантайме и вся программа посыпалась и неизвестно как ты это отловишь потому что имп поинтер уже ссылается не туда). Не говоря уже о том что вместо таких извратов может лучше писать сразу на ц++?
Первое, такой выход дает скорость быстрее виртуальных методов С++ по версии Эша.Третье, обычно, такой механизм наружу не выпячивают и предупреждают. Если же уж хакер был настолько идиoтом, что влез во внутреннюю структуру объекта и перегрузил приватную функцию, то кто ему доктор? Он и по смещению бед может натворить.
>Отлично, где можно найти библиотеку коллекций/алгоритмов которая бы это использовала(типа STL)? А иначе это все только на бумаге.
Я не хочу тебя огорчать, но, это только в С++ такая штука являецца костылем, типа СТЛ, который сбоку припеку и упоминаецца отдельно, что и неудивительно. Смотри в стандартную некстстеповую (все классы, начинающиеся с NS) и кор файндейшен (все функции и структуры, начинающиеся с CF) библиотеку. Там все это есть. И коллекции, и алгоритмы, которые используют и имп кэш, и инлайнинг, и черт знает что еще.
>Связан, когда проишодит посыл мессаджа, рантайм вначале смотрит в кеш не отрезолвлен ли адрес метода уже. Это и называется IMP кешем, и оно выделено крансым на листинге на который я ссылался.
Этот механизм являецца частью месседжинга и имп-кешем не называецца. Собсно, об этом я и говорил изначально, говоря, что «objc_msgsend — это то, что скрываецца под синтаксисом вызова любого метода и не связан с IMP-cache никак.»
Внутреннее кеширование есть, но его проверить сложно, т.к. рантайм сам занимаецца резолвом и предсказать, когда лезет в кэш, а когда и без кэша хорошо живет невозможно, посему и замерить невозможно. Именно поэтому, имп — кеш — то, что сказал я, а внутреннее кэширование замеряют по станадртному месседжингу.
Вот имп-кеш по версии Эша:}
— (void)_stubMethod}
ДЫк в том-тьо и дело ,что читаемость, зависящая от именования переменных — это плохо. И именно об этом я и говорил. Скажем, если у нас подряд несколько вызовов одной и той же функции с разными входами, то с читаемостью вновь будут вопросы, т.к. с переменными прийдецца, ибо они же однотипные извращацца.
Затем, что в моем случае это не простительно таки. А, если уж допустил ошибку, то надо ее признать и жить с ней дальше, не? Все-таки, доказывать до последнего свою правоту, даже, если не прав, таки несколько глупо, да?
Ну да. Но, позвольте, если вы уже делаете специализированный чип, гед все решаецца не за счет наращивания мегагерцев, а за счет параллелизма, то высокий уровень не применим. Я в этом контексте не особо понимаю профит от систем С. С тем же успехом можно было бы все и из матлаба генерить, ибо и там, и там теряецца основная и главная фишка, а именно — высокий параллелизм при низкой частоте, ибюо оптимизация ни к черту.
В то же время, С и АСМ сравнивать некорректно, тк. в основном С-копилятор выдась код не хуже, а зачастую и лучше челвоека, если не требуецца применение каких-то фич процессора, которые сам по себе компилятор вставлять не будет, либо будет вставлять криво.
Беру таймаут. Я потерялся в том ,о чем с вами спорил и не могу вспомнить. Вместо этого, я просто скажу вам, как аргумент к превозмоганию С++ над высокоуровневыми языками, что я только видел, как у красивой девушки на голове сидела шиншилла и гадила, тем самым выражая свое мнение об этом вашем высоком уровне.
З.Ы. Хоть это я это и вставил в метафорическом контексте, но оно вполне себе рельно только что имело место быть.
Ага. Можно отстрелить себе ноги, а можно построить самолет. Другое дело, что когда программеру не дают возможности отстрелить себе ноги, самолета также точно не выйдет.
Только формошлепание и может выполняцца в рамках обжектива. В остальных случаях, вы бы не смогли написать фразу: «Да, можно использовать чистый С. Но реально мне подобного приходилось видеть мало.», т.к. кор фреймворки испоьзуюцца на каждом шагу.
Тю. Нзш.
Угу. В обязательном порядке.
Иностранцы годные знают все это, разные демперы — нет, но им и платят соответственно.
Конечно же.
Синглтон тоже.
C99. А вообще, смотрите на фишки ЖСС.
>Что касается знания чистого С. Да, можно использовать чистый С. Но реально мне подобного приходилось видеть мало.
Угу. Дык, вы формошлепите. Так бы сразу и сказали. Ибо только в этом случае вы не пользуетесь фреймворками, типа Core Foundation, Core Graphics, Core Text и подобными корами.
>Так что на мой взгляд примерно одинаково переходить на ObjC что с джавы, что с плюсов.
Дял шлепания формочек — вообще без разницы с чего на что переходить. И счастью вашему нет предела, что появился сториборд и ARC, ибо теперь можно шлепать еще больше.
А где он обсуждался? А то видел статейки ,но все они какие-то грустные и не учитываеют специфики ответственности.
>Забей, я же тебя специально спровоцировал. Даже странно, что получилось так легко :)
Ну-ну. Не стоит теперь отмазывацца, стесняцца и переводить все в шутку. Ты намеревался настучать. В этом нет ничего страшного. Вон, вся Германия стучит, и ничего.
Более того, я выдвигаю тебя на пост почетного Павлика Морозова, который раньше занимал ныне почивший в бозе стукачок Антошка Мартыненко.
Посему, предлагаю афилированным голосование. И лично я буду голосовать за Лупана и никак иначе.
Еще предложения, господа присяжные — заседатели?
Да я-то, как раз, понимаю. Дял вас, как челвоека с ГСМ, перевести на более примитивный и понятный язык? Мне не жаль напрячься ради более слабого оппонента, дабы он понял мои сентенции.
Керниган и Ритчи — «Язык программирования С»
А дальше, считай, что ты знаешь все, что надо, когда можешь
— написать мемкопи,
— определить, какая на машине эндианнес и конвертнуть ее в ту, что тебе нужна,
— написать циклический буффер, принимающий на вход заданный при инициализации произвольный размер да так, чтобы через кажыдй считываемый элемент он оповещал твой код о том, что произошло считывание, причем, чтобы считывание или запись были возможны с оконным сдвигом, а не только со сдвигом на размер элемента
— мог создать такое дерево, чтобы его можно было обойти двумя способами (рекурсивный и циклический)
— создать систему логгирования с возможностью задания различной глубины так, чтобы не генерился лишний код, когда тебе это не надо
— создать на основе С синглтон
Ну где-то так. Если это все сделаешь, считай, что к написанию кода на С-шной части маковской библиотеки готов (т.к. все это или куски этого иногда приходицца пользовать, особенно, если хоть когда-нить столкнешься с Accelerate Framework).
Угу. Есть только одна проблема. У вас нет представления об обжективе. Вообще никакого. Иначе, вы бы не написали такую фигню: «если для Вас процесс программирования сводится к использованию фреймворков, то тогда конечно». Поэтому, вы не можете оценить, какие представления об обжективе имею я.
Хотя да, что можно ожидать от формошлепа — явера? Вы вообще в курсе, что стандартная библиотека на обжективе — это фреймворки? А в курсе, что NSObject — часть фреймворка? Или вы, аки настоящий красноглазик писали свою реализацию рут объекта? Хоть когда-нить видели CoreFoundation и Foundation фреймворки и представляете, что они есть такое?