Скажите, а реально ли открыть компанию в UK, и под нее получить временный вид на жительство (как это возможно в Австрии, к примеру), и постоянно его продлевать? Через эту же компанию можно и принимать оплату.
Возможно. Скажу честно, с darwin/xnu мне работать не приходилось. Один раз, году этак в 2003, мне пришлось туда залезть, уж и не помню почему. Больше никто и никогда не заказывал ничего с ним связанного. Так что моя позиция слаба.
Сравнивать Linux Kernel vs darwin/xnu как раз неинтересно. В низкоуровневых системах как очень много общих техник, там сложнее найти разницу, чем общие точки.
Не соглашусь. RC как раз является базой ООП. Часто его не видно, но он есть там, в недрах реализации объкта. В системах с автоматической сборкой мусора сложно представить что-то другое.
Необходимость в RC появляется в больших и недетерменированных системах, где сложно предсказать поведение — к сожалению, ООП часто приводит именно к этому. В небольшом функциональном проекте с десятком процессов просто нет необходимости в этой технике. И даже в ядре Linux RC появился только году так в 2006, а плотно использоваться стал еще позже. Да и сегодня при написании всякого рода драйверов RC используется относительно редко — драйвер создает несколько своих объектов, которые сам же при выходе и уничтожает. Гораздо чаще, на порядок чаще объекты синхронизации ядра это спинлоки и семафоры, в некоторых случаях даже просто атомарные счетчики, редко RCU.
Да. Но дело в том, что в ни в стандартном C, ни в расширенном gcc нет встроенного механизма reference counting — просто потому, что это не языки, изначально построенные для ООП. Этим особенно и интересен refcounting в ядре — это относительно недавно внедренная конструкция. Когда я начинал работать с ядром, проблемы структур с общим доступом каждый решал как мог, и иногда мне попадались довольно странные идеи, явно списанные из каких-то других OS. Ядро вообще достаточно долго служило испытательным полигоном для людей из академии, которые притащили в него множество сложных и интересных для теоретиков идей и конструкций. В частности, постепенно ядро вбирало в себя все больше и больше различныех методик из ООП. Хорошо это или плохо — это уже филосовский вопрос.
Я смотрю на то, что относительно недавно появился ARC. Это шаг в направлении автоматизации — теперь объекты освобождаются автоматически. И вот в iOS наблюдается странная ассиметрия: объекты надо создавать, но не надо освобождать. Это нелогично. Более того, автоматическая алокация объекта с точки зрения управления памятью — это просто, это намного проще, чем ARC. Мне очень сложно представить себе ситуацию, в которой попытка записи в неалоцированнай объект (и как следствие invalid page fault) не является багом.
Я не сравниваю коллекции в Objective C и в ядре: в ядре нет коллекций. Я просто привел список основных примитивов, доступных в обеих системах для организации данных. И именно для того, чтобы показать их разницу.
В основном мне интересен именно тот факт, что один и тот же концепт, причем практически неизменном виде, присутствует в таких перпендикулярных системах, как iOS достаточно высокого уровня, и низкоуроневое ядро Linux.
Относительно конструкции NSSting stringWithFormat:
На мой взгляд, это достаточно хороший индикатор того, куда может начать мигрировать iOS, а именно, в сторону полной автоматизации управления памятью. Как вы понимаете, эта конструкция появилась не из головы какого-то разработчика. Она была описана в архитектуре, прошло достаточно серьезные обсуждения, была одобрена и внедрена в язык. Если в ближайшие годы Apple не откажется от развития Objective C, полностью переорентировавшись на Swift, то мы увидим еще много интересных изменений.
Сегодня объекты нужно создавать явным образом. При этом уничтожаются они автоматически. Это идет вразрез с общей идеологией изменений языка.
Поглядим.
Необходимость в RC появляется в больших и недетерменированных системах, где сложно предсказать поведение — к сожалению, ООП часто приводит именно к этому. В небольшом функциональном проекте с десятком процессов просто нет необходимости в этой технике. И даже в ядре Linux RC появился только году так в 2006, а плотно использоваться стал еще позже. Да и сегодня при написании всякого рода драйверов RC используется относительно редко — драйвер создает несколько своих объектов, которые сам же при выходе и уничтожает. Гораздо чаще, на порядок чаще объекты синхронизации ядра это спинлоки и семафоры, в некоторых случаях даже просто атомарные счетчики, редко RCU.
В основном мне интересен именно тот факт, что один и тот же концепт, причем практически неизменном виде, присутствует в таких перпендикулярных системах, как iOS достаточно высокого уровня, и низкоуроневое ядро Linux.
На мой взгляд, это достаточно хороший индикатор того, куда может начать мигрировать iOS, а именно, в сторону полной автоматизации управления памятью. Как вы понимаете, эта конструкция появилась не из головы какого-то разработчика. Она была описана в архитектуре, прошло достаточно серьезные обсуждения, была одобрена и внедрена в язык. Если в ближайшие годы Apple не откажется от развития Objective C, полностью переорентировавшись на Swift, то мы увидим еще много интересных изменений.
Сегодня объекты нужно создавать явным образом. При этом уничтожаются они автоматически. Это идет вразрез с общей идеологией изменений языка.
Поглядим.