Логика как в статье — почему бы и нет. Я уж не знаю про скорость (да и игровая логика не то чтобы сильно требовательна к ресурсам), но одно серьезное препятствие это конечно громоздкость.
Вот например шейдеры. Там блюпринты прижились и используются для создания сложных материалов, но в итоге получается огромная куча блоков, в которых несколько сложно разбираться. Хотя блоки комментариев спасают.
Чуть ли не главная фишка блюпринтов же — дать возможность пилить шейдеры и логику дизайнерам, а не программистам. Это очень круто, хоть я и сам программист. Теже материалы делать блюпринтами очень интересное занятие и куда более интерактивное, нежели писать код.
Судя по различным обсуждениям, все сводится к одному — делать на блюпринтах все до тех пор, пока не упрешься во что-то. Будь это возможности, производительность, читабельность. Тогда что-то можно перенести на плюсы. Но это все так, инди, аркадки. Что там с ААА не слышал — насколько там блюпринты популярны. Не удивлен, если блюпринты там даже в расчет не берутся.
Спасибо за минусы, но можно поинтересоваться, за что? Я думаю всем будет полезно узнать как же все работает на самом деле, раз я написал что-то неправильно.
Да ничем, по сути. Просто в первом случае ARC выдает ошибку, а во втором случае выдает только предупреждение — мол, надеюсь ты знаешь, что ты делаешь, потому что я не ручаюсь за возвращаемое значение. И это действительно так — с performSelector предупреждение и гласит, что может быть утечка памяти — ARC дает возможность сделать такое, но не ручается за управление памятью, потому что он без понятия о том, что делать с возвращаемым значением.
Такие уж костыли на пути отказа от динамики — какую-то обратную совместимость надо было оставить. До ARC это все было валидно и предупреждало только о неизвестном селекторе. С ARC всеми силами предупреждают, что код небезопасен и лучше так не делать. Из swift это вообще полностью выпилили как небезопасный код
The performSelector: method and related selector-invoking methods are not imported in Swift because they are inherently unsafe.
Насколько я помню, тут все из-за возвращаемого значения. По-умолчанию для всех подобных вызовов возвращаемым типом является id и ARC не знает, что с ним делать. Для ARC эта информация обязательна.
Достаточно в проекте отключить ARC и подобный код будет без проблем компилироваться и максимум выдаст предупреждение о неизвестном селекторе. Этот код полностью валидный, но с приходом ARC он теперь является ошибкой.
И все из-за ограничений ARC, хотя в этой одной строчке вся суть механизма сообщений — посылай что хочешь кому хочешь, это не вызов функции. Сейчас же с появлением ARC и swift исчезает все больше динамики, а swift так вообще просто еще один мультипарадигменный язык со своим синтаксическим сахаром.
На эти и многие другие вопросы можно найти ответы здесь developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html Рантайм умеет многое. Что касается objc++, то я не слышал, чтобы он чем-то отличался особенным. Это просто расширение для частичной поддержки C++. Основные проблемы конечно, когда мешаешь objc и C++, но так все очень прилично.
Это мои размышления на основе того, как работает вызов функций вообще — поэтому у меня и вопрос на счет того, зачем type encoding нужен рантайму, если на уровне асма все и без него по идее должно рабоать. Суть в том, чтобы после вызова вернуть все в прежнее состояние. Это и может сделать objc_msgsend с той лишь разницей, что после эпилога он сделает вызов найденного метода и получится, будто мы передали все эти аргументы прямо в метод, а не в objc_msgsend. Главное не трогать аргументы и стек, в котором могут лежать другие аргументы. Сделать это не так сложно — calling conventions действительно творят чудеса
Ну как. На входе objc_msgsend в стек кладем все регистры, где обычно лежат аргументы. Дальше делаем свои дела, находим функцию. Восстанавливаем все регистры и возвращаем указатель стека на место, где он был на входе в objc_msgsend. Т.е. все регистры остаются как были, а стек указывает на то место, где лежат остальные аргументы. Вызываем наконец метод уже после эпилога objc_msgsend. Все выглядит так, будто не objc_msgsend вызвали, а просто напрямую метод класса. Просто перенаправляем вызов по нужному адресу.
Но зачем его парсить? objc_msgsend ничего с аргументами делать не должен — только найти реализацию метода и передать управление туда с сохранением состояния регистров и стека перед вызовом objc_msgsend. На уровне асма все вызовы методов превращаются в обычный вызов C функции со стандартным calling convention — несколько аргументов в регистрах, остальное в стеке. Опять же, с переопределением методов для jailbreak твиков можно много чего творить со списком аргументов. Обычное дело — заменить все аргументы на void* или id, если не знаешь их типов или вообще пофиг на них.
Например, мы не разобрались с возвратом результата из вызываемых методов
Хорошо бы коснуться type encoding у методов классов. Как это работает и зачем оно вообще нужно. Потому как на уровне асссемблера это все не нужно. Есть calling conventions, они все сделают — все методы используют стандартные ARM calling conventions, если говорить об iOS. С переопределением методов очень просто передать в метод аргументы совершенно не тех типов, либо вообще передать меньше, чем надо. Получишь или UB, или segmentation fault. Поэтому интересно, что с этой информацией делает рантайм.
Единственное место, где реально нужно знать type encoding, это NSInvocation, где аргументы передаются как массивы байтов, а типы берутся как раз из type encoding. Естественно, передать неправильные аргументы там можно запросто.
Насчет возвращаемого значения, опять же, calling conventions все за нас сделают. Они на то и придуманы, чтобы все работало само собой, так сказать.
Вообще да, к селекторам, по хорошему, так же привязан type encoding, который дает понять примерно какого типа аргументы. Но это информация уже конкретного класса, а не самого селектора. Селектор это имя метода, которое никак не привязано к конкретному классу и никак не описывает типы аргументов. Селектор «value» может возвращать какой угодно тип в зависимости от того, какому классу этот селектор дать. Он даже может означать одновременно метод класса и метод экземпляра. Лишний раз можно заглянуть в рантайм API developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html
Функции для работы с селекторами не позволяют получить никаких типов. Только имя, а это та самая С строка. Тип получается только для методов с помощью method_getTypeEncoding. Туда передается тип Method, который можно получить только от конкретного класса, передав ему тот самый универсальный селектор. И вот Method уже должен внутри себя содержать и селектор, и type encoding.
Так что представленный код выглядит довольно странно. Не вписывается в логику самого языка и его рантайма. И не вписывает в то, как это все хранится в бинарнике, где селекторы лежат отдельным списком С литералов, а отдельно лежат метаданные классов со ссылкой на эти литералы для каждого конкретного метода.
Естественно там есть таблицы для быстрого поиска методов по селекторам. Никто при каждом вызове strcmp, скажем, не вызывает. В подробности того, какая именно там структура данных используется, я правда не вдавался. Но то, что вызов objc метода делается довольно быстро, это знаем точно www.mikeash.com/pyblog/performance-comparisons-of-common-operations-leopard-edition.html
То, что вы вывели, всего навсего адреса селекторов в памяти. Они ничего принципиально не значат. В конечном итоге каждый селектор это просто С строка и не важно в какой области памяти процесса она лежит. Естественно строковые литералы будут лежать в другом месте совсем — селекторы таковыми и являются. Откройте любой objc бинарник в дизассемблере и среди строковых литералов найдете все методы и классы. Мы можем хоть в зашифрованном виде хранить эти строки и расшифровывать только при вызове метода через какой-нибудь NSInvocation — все будет работать как по маслу. Рантайм всего лишь ждет от нас строку и по ней найдет метод, если он есть у класса. Где бы она ни находилась — в литералах, куче, стеке. В этом весь смак objc runtime.
Знания никогда не пропадут, а вот возможности запросто. Apple говорит, но там есть хитрость. Насколько помню, если swift класс используется в objc коде, то там действительно все как в старом добром objc runtime. Но если swift класс не используется в objc, то он превращается, по сути, в подобие C++ классов с жестко заданной таблицей виртуальных функций, которая находится после всех метаданных. Никаких селекторов, прямые вызовы методов. Swift на самом деле сильно другой внутри. Есть вот такая лекция небольшая на эту тему www.youtube.com/watch?v=Ii-02vhsdVk
Как это сильно отличаются? Селектор это строка и ничего более. Никакого name mangling у objc нет. Все скомпилированные методы классов в бинарнике попадают в секцию, где лежат в виде обычных строк. Уже в другой секции есть списки методов со ссылками на этим строки. Так же рядышком лежат type encoding для каждого метода с описанием типов аргументов. Как эти методы были написаны программистом, так они и попадают в скомпилированный код, без единого изменения. Разве что из-за type encoding теряется информация о типах.
Собственно, если бы что-то сильно отличалось, то были бы проблемы с твиками для джейлбрейка. В твиках мы обычные строки конвертируем в селекторы не имея на руках даже прототипов классов. Просто берется С строка вида «initWithKey:value:» и передается рантайму, чтобы он уже подменял реальный метод с таким селектором нашей реализацией. Мы сами знать не знаем ни о каких хедерах и классах с таким методом, компилятор ничего о них не знает.
Да, добавлять и подменять в рантайме методы можно и это очень и очень просто. Вот для удаления API нет.
Любой анонимус может воспользоваться любой другой базой для определения координат по mac-адресу. И очевидно, что есть базы, которые содержат намного больше информации, чем яндекс. Тот же гугл и apple.
Первый тип это уже другая тема — это именно пополнение базы. Статья как раз о втором запросе, и он явно не отключается в настройках, только полным отключением location services.
Я опубликовал вам реальный запрос из Windows Phone 7, который некоторое время назад работал и отправлял все, что вам так не нравится (он и сейчас работает, возвращает валидный ответ, что координаты получить не удалось). Хотите большего — изучайте тему и перестаньте голословно утверждать то, о чем вы не имеете малейшего понятия.
Хотите узнать как и когда apple что-то отправляет — изучайте. Я вам все рассказал и намекнул, публиковать здесь форматы бинарных пакетов у меня нет никакого желания.
А согласен я буду тогда, когда вы научитесь читать других и перестанете откровенно врать в ответ. Мы здесь все взрослые люди и если вам сказали, что что-то отправляется и протоколы были изучены, то скорее всего так оно и есть. Просить опубликовать так вот сходу результаты чужих исследований и ставить условия несколько некорректно, не находите? Если бы у меня было желание делиться этим со всеми, я бы давно поделился. Эти протоколы известны мне не один год.
Опять вы врете. Ниодного доказательства с вашей стороны не было. Все выши скриншоты не имеют никакого отношение к вопросы.
Контроль за отсутствием собственных функций геолокации осуществляется в AppStore
Кажется вы совершенно не в состоянии понять, что вам пишут другие. Еще раз перечитайте мой пост — ничего подобного там не сказано. Более того, имея MAC и SSID текущей подключенной сети вы таки можете получить примерное местоположение и Apple скорее всего ничего вам на это не скажет.
Вот например шейдеры. Там блюпринты прижились и используются для создания сложных материалов, но в итоге получается огромная куча блоков, в которых несколько сложно разбираться. Хотя блоки комментариев спасают.
Чуть ли не главная фишка блюпринтов же — дать возможность пилить шейдеры и логику дизайнерам, а не программистам. Это очень круто, хоть я и сам программист. Теже материалы делать блюпринтами очень интересное занятие и куда более интерактивное, нежели писать код.
Судя по различным обсуждениям, все сводится к одному — делать на блюпринтах все до тех пор, пока не упрешься во что-то. Будь это возможности, производительность, читабельность. Тогда что-то можно перенести на плюсы. Но это все так, инди, аркадки. Что там с ААА не слышал — насколько там блюпринты популярны. Не удивлен, если блюпринты там даже в расчет не берутся.
Такие уж костыли на пути отказа от динамики — какую-то обратную совместимость надо было оставить. До ARC это все было валидно и предупреждало только о неизвестном селекторе. С ARC всеми силами предупреждают, что код небезопасен и лучше так не делать. Из swift это вообще полностью выпилили как небезопасный код
developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html
Достаточно в проекте отключить ARC и подобный код будет без проблем компилироваться и максимум выдаст предупреждение о неизвестном селекторе. Этот код полностью валидный, но с приходом ARC он теперь является ошибкой.
Хорошо бы коснуться type encoding у методов классов. Как это работает и зачем оно вообще нужно. Потому как на уровне асссемблера это все не нужно. Есть calling conventions, они все сделают — все методы используют стандартные ARM calling conventions, если говорить об iOS. С переопределением методов очень просто передать в метод аргументы совершенно не тех типов, либо вообще передать меньше, чем надо. Получишь или UB, или segmentation fault. Поэтому интересно, что с этой информацией делает рантайм.
Единственное место, где реально нужно знать type encoding, это NSInvocation, где аргументы передаются как массивы байтов, а типы берутся как раз из type encoding. Естественно, передать неправильные аргументы там можно запросто.
Насчет возвращаемого значения, опять же, calling conventions все за нас сделают. Они на то и придуманы, чтобы все работало само собой, так сказать.
Функции для работы с селекторами не позволяют получить никаких типов. Только имя, а это та самая С строка. Тип получается только для методов с помощью method_getTypeEncoding. Туда передается тип Method, который можно получить только от конкретного класса, передав ему тот самый универсальный селектор. И вот Method уже должен внутри себя содержать и селектор, и type encoding.
Так что представленный код выглядит довольно странно. Не вписывается в логику самого языка и его рантайма. И не вписывает в то, как это все хранится в бинарнике, где селекторы лежат отдельным списком С литералов, а отдельно лежат метаданные классов со ссылкой на эти литералы для каждого конкретного метода.
Собственно, если бы что-то сильно отличалось, то были бы проблемы с твиками для джейлбрейка. В твиках мы обычные строки конвертируем в селекторы не имея на руках даже прототипов классов. Просто берется С строка вида «initWithKey:value:» и передается рантайму, чтобы он уже подменял реальный метод с таким селектором нашей реализацией. Мы сами знать не знаем ни о каких хедерах и классах с таким методом, компилятор ничего о них не знает.
Да, добавлять и подменять в рантайме методы можно и это очень и очень просто. Вот для удаления API нет.
Хотите узнать как и когда apple что-то отправляет — изучайте. Я вам все рассказал и намекнул, публиковать здесь форматы бинарных пакетов у меня нет никакого желания.
А согласен я буду тогда, когда вы научитесь читать других и перестанете откровенно врать в ответ. Мы здесь все взрослые люди и если вам сказали, что что-то отправляется и протоколы были изучены, то скорее всего так оно и есть. Просить опубликовать так вот сходу результаты чужих исследований и ставить условия несколько некорректно, не находите? Если бы у меня было желание делиться этим со всеми, я бы давно поделился. Эти протоколы известны мне не один год.
Кажется вы совершенно не в состоянии понять, что вам пишут другие. Еще раз перечитайте мой пост — ничего подобного там не сказано. Более того, имея MAC и SSID текущей подключенной сети вы таки можете получить примерное местоположение и Apple скорее всего ничего вам на это не скажет.