WWDC.

А его преимуществом над C++ c учетом наличия shared_ptr является ...?

Э-э-э... я как-то не очень понял, при чём тут shared_ptr.

Кресты любят топить за необходимость ручного менеджмента памяти, но при наличии shared_ptr этот аргумент устарел.

Так что на счет плюшек Swift, которых нет изкоробки в C++, который уже много лет как свободный и нативнокомпилируемый.

Кресты любят топить за необходимость ручного менеджмента памяти, но при наличии shared_ptr этот аргумент устарел.

Во-первых, не устарел. shared_ptr — это не полноценный GC, это всего лишь счётчик ссылок. Что а) ненадёжно (получить случайно цикл — как два байта переслать), и б) медленно (освобождение верхушки разлапистого дерева приводит к рекурсивному освобождению всего вообще).

Во-вторых, где, собственно, дженерики? И только не надо мне на темплейты показывать, темплейты — это не дженерики, это плохо приляпанная макросистема, которая как-то, время от времени, дженерики имитирует.

shared_ptr — это не полноценный GC

Да, с ним ты можешь контролировать время жизни объекта и получаешь нормальные деструкторы в отличии от того говна, которое предлагается в нагрузку к GC

Во-вторых, где, собственно, дженерики?

А что именно вас так восхищает в дженериках, чего нет в темплейтах, которые более гибкие и удобные для использования?

Да, с ним ты можешь контролировать время жизни объекта

Сама идея GC в том, чтобы переложить заботу о времени жизни объекта на компьютер. Он железный, пусть он работает.

Высказанные аргументы ты, по-видимому, решил проигнорировать.

А что именно вас так восхищает в дженериках, чего нет в темплейтах, которые более гибкие и удобные для использования?

Раздельная компиляция? Не слышали?

Полиморфная рекурсия — тоже не?

Про «удобные» я вообще молчу, это полный бред. Там даже нельзя явно прописать требования к аргументам.

> Там даже нельзя явно прописать требования к аргументам
Но ведь это же лошь. Готов пройтись по конкретным требованиям к аргументам, которые я реализую в небольших кусочках кода.

> Раздельная компиляция? Не слышали?
В чем бенефит? Поставлять скомпилированные темплейты? Или вопрос во времени компиляции?

> Сама идея GC в том, чтобы переложить заботу о времени жизни объекта на компьютер.
Так shared_ptr и перекладывает. Причем не утруждая программиста мученими со временем жизни открытых ресурсов (сетевые сессии, коннекты к БД, etc), которые надо ручками закрывать. Вместо этого поручая рутину компьютеру, через деструкторы.

> > Высказанные аргументы ты, по-видимому, решил проигнорировать.

> Во-первых, не устарел.
В смысле первые версии были созданны очень давно? Тогда это не аргумент. Или под устареванием подразумевается что-то иное?

> медленно (освобождение верхушки разлапистого дерева приводит к рекурсивному освобождению всего вообще)
А GC волшебным образом сократит это время? Или просто начнет тормозить в недетерменированный момент времени?

> ненадёжно (получить случайно цикл — как два байта переслать
Циклические зависимости - это уже архитектурные проблемы. Причем очень и очень серьезные.


P.S.

> Полиморфная рекурсия — тоже не?
Вот про это действительно не слышал, с удовольствием ознакомлюсь. Ссылки на русско/англоязычные ресурсы подойдут.

Готов пройтись по конкретным требованиям к аргументам, которые я реализую в небольших кусочках кода.

OK, пусть задан некий интерфейс IInterface. Нужен шаблон, по заголовку которого понятно, что он гарантированно компилируется для всего, что этот интерфейс реализует.

В чем бенефит? Поставлять скомпилированные темплейты? Или вопрос во времени компиляции?

И то, и другое, и компилировать разными компиляторами, и точно знать контекст, в котором раскрывается шаблон, и много чего ещё.

Сама идея GC в том, чтобы переложить заботу о времени жизни объекта на компьютер.

Так shared_ptr и перекладывает.

Ну так ты же заговорил о том, чтобы работать с ней вручную.

Во-первых, не устарел.

В смысле первые версии были созданны очень давно? Тогда это не аргумент. Или под устареванием подразумевается что-то иное?

Нет, блин, в смысле, что тебе тут же приведено, почему shared_ptr не годится.

медленно (освобождение верхушки разлапистого дерева приводит к рекурсивному освобождению всего вообще)

А GC волшебным образом сократит это время? Или просто начнет тормозить в недетерменированный момент времени?

Во-первых, может и сократить. Во-вторых, он не остановит выполнение в произвольный, непредсказуемый момент времени (как в случае с подсчётом ссылок), а будет работать параллельно с основным выполнением.

ненадёжно (получить случайно цикл — как два байта переслать

Циклические зависимости - это уже архитектурные проблемы. Причем очень и очень серьезные.

Это у вас в плюсах они «архитектурные». А в языках с GC — ничего особенного.

Полиморфная рекурсия — тоже не?

Вот про это действительно не слышал, с удовольствием ознакомлюсь. Ссылки на русско/англоязычные ресурсы подойдут.

Да чего там читать. Ну, представь себе какой-нибудь дженерик, вроде G<T>. И функция (тоже дженерик) f, которая, будучи вызвана с типом-аргументом T (то есть, как f<T>(...)) при определённых условиях (не всегда) рекурсивно дёргает себя же, но как f<G<T>>(...).

На шаблонах ты это фиг нарисуешь. Потому что они — макросистема над убогой системой типов C++.

он не остановит выполнение в произвольный, непредсказуемый момент времени (как в случае с подсчётом ссылок)

Смешно. Подсчет ссылок начнет освобождение в абсолютно детерменированный момент: когда будет удалена последняя ссылка на объект. Про постоянно работающий GC вы не плохо фантазируете.

будет работать параллельно с основным выполнением

На отдельный ЭВМ? Или у вас все ПО до сих пор одно ядро использует и остальные 7 можно отдавать для GC?

по заголовку которого понятно

Вопрос был про требования к аргументам или про заголовки?

он не остановит выполнение в произвольный, непредсказуемый момент времени (как в случае с подсчётом ссылок)

Смешно. Подсчет ссылок начнет освобождение в абсолютно детерменированный момент: когда будет удалена последняя ссылка на объект. Про постоянно работающий GC вы не плохо фантазируете.

Абсолютно детерменированный с точки зрения компьютера. Для программиста он непредсказуем.

будет работать параллельно с основным выполнением

На отдельный ЭВМ? Или у вас все ПО до сих пор одно ядро использует и остальные 7 можно отдавать для GC?

А это не принципиально. Даже если он просто в какие-то моменты будет переключаться на GC, делать немножко работы, а затем переключаться обратно — нет никакой разницы. Работали же программы в параллель друг с другом даже на одноядерных системах.

по заголовку которого понятно

Вопрос был про требования к аргументам или про заголовки?

Понятие «заголовок» можно понимать расширенно. Это должен быть компактный кусок кода. Во всяком случае, сформулированное условие должно укладываться в две-три строчки максимум.

Абсолютно детерменированный с точки зрения компьютера. Для программиста он непредсказуем.

Если пихать ссылки на все и повсюду, чтобы все знали обо всех, да еще и обмазаться парочкой циклических зависимостей, то да, будет очень сложно.
Если же в проекте есть человек, который отвечает за архитектуру и умеет нормально проектировать, то все будет ок.

А это не принципиально. Даже если он просто в какие-то моменты будет переключаться на GC, делать немножко работы, а затем переключаться обратно

Другими словами: твой софт может в какой-то неясный момент времени начать тормозить. Совсем немножко.

Посмотрел презентацию Apple на WWDC... Куда оно катится? Где они нашли всех этих отморозков?

Приводит в уныние

1. Слово «революционный» заменило собой слово «новый». Обычные новые вещи называются революционными, в то время как никаких революций не было с презентации первого айфона.
   
   
2. Оборот «действительно замечательный» (really great) звучит каждые пять минут. При этом на экране заурядные вещи. Зачем нужны дополнительные усиляющие слова, если все действительно так замечательно?
   
   
3. «Фишки». Куча «теперь можно делать вот так» без ответа на вопрос «зачем так вообще делать».
   
   
4. Мудак с пузом изображает некое подобие танца на сцене, делая вид, что это его любимое занятие. [Станиславский mode] Не верю! [/]
   
   
5. El Capitan.
   
   
6. «Эл кэпицэн»! Если уж выбирать имя, то хотя бы такое, чтобы любой из вас его мог произнести.

Рано или поздно, апгрейд железа неминуем, во что к тому времени превратится единственный нормальный юникс, и куда бежать?

А нормальный GC позволит этому человеку заниматься действительно интересными вещами, а не за циклическими ссылками следить.

А нормальный GC позволит этому человеку тормозить

slowfix

чувак, я семь лет собирал силы духа на интель...
поставил на него ОСХ и через 15 минут использования стёр к едреням...

без их железа , единственный десктопный юникс - унылейшее созерцание каких-то элементов интерфейса.

А как СнежныйЛеопард дысал, как дысал.. красивостями. и ПРОСТОТОЙ/изящностью ИНТЕРФЕЙСА.

Что может быть интереснее проектирования архитектуры приложения?

Кодирование очередного алгоритма из википедии? Или разгребание запроса из БД ручками? Так ведь это все уже написано до нас.

Так у меня есть их железо. И будет. Другой вопрос, как этим пользоваться.

Что может быть интереснее проектирования архитектуры приложения?

Воот. Начинаешь понимать, что циклические ссылки разгребать — это неинтересно, а надо архитектуру проектировать.

Так ведь это все уже написано до нас.

Как и простое решение «проблемы циклических ссылок».