Презентация Герба Саттера про Visual C++ и C++11 на конференции BUILD

[Malinnikov]

Герб уже работает над заявкой в Комитет, посвященной сборщику мусора.

Проклятье! Неужели ребята в C++ стали создавать так много мусора, что постоянно всплывает тема о его сборщике?

[ixSci]

Некоторые алгоритмы требуют его наличия для эффективного исполнения. Гернб упоминал об этом неоднократно.

[xiWera]

А можно пример такого алгоритма? Потому-что, сдаётся мне, любой алгоритм со своей собственной, заточенным под него логикой алокации, будет эффективней чем сборщик мусора.

[ixSci]

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

[ixSci]

Что-то нагуглилось

[xiWera]

Ага, то есть алгоритм, в котором всего лишь подсчёт использований ноды хорошо ложится на «идеологию» референс-счетчиков. То есть один из этапов алгоритма — учет использования «нод». Ой как нехорошо при этом говорить что он ТРЕБУЕТ сборщика мусора для эффективности.

[ixSci]

Не нравится слово обратитесь к Гербу. Я передал то, что слышал в его выступлениях. Сам я не сталкивался с такой необходимостью. А ссылка, которую я привёл есть лишь результат ~10 секундного «гугления». Я не знаю о каких конкретно алгоритмах говорил Герб.

[Radagast]

в этой презентации Герб упомянул lock-free collections (кажется, так), для которых был бы желателен GC. И он подчеркнул, что этот сборщик будет опциональным и использоваться только там, где действительно нужен. В остальном он очень доволен нынешней моделью управления памяти в С++11 на основе разных smart pointers.

[Offenso]

Но все мы знаем историю TF2 к чему это приведет.

[DZhon]

erdani.com/publications/cuj-2004-10.pdf Пожалуйста, реализация Lock-free контейнеров, статья написана Андреем Александреску.

[Gorthauer87]

Любая продвинутая функциональщина точно опирается на сборщик. Да и простейшие лямбды без сборки мусора не так красивы и эффективны.

[Zay4egg]

Можно пример простейших лямбд, становящихся более красивыми при наличии GC?

[jack128]

любые ленивые вычисления. IEnumerable/Enumerable из дот нета

[DZhon]

Возможно слово «требуют» не совсем корректно, но уж «желательны» подавно. Наиболее простой пример — асинхронное сетевое взаимодействие. Если посмотреть на тот же boost::asio, то мы имеем чрезвычайно мощную и органичную библиотеку, однако в практическом применении практически всегда вынуждены окружать код вокруг нее счетчиками ссылок. Уж лучше тогда полноценный GC с поколениями и пулами.

[Gorthauer87]

А тем временем студия так и не умеет мегаполезные variadic template'ы

[ixSci]

Вы читали, что написано в статье?

[9mm]

Еще пару лет и c++ по возможностям с D сровняется, но что будет с его синтаксисом… я боюсь.

[Athari]

что будет с его синтаксисом… я боюсь

Будет? По-моему, уже. И давно.

virtual void f() = 0;
while (*s1++ = *s2++);
char* c1, c2;
void *(*f)(void*);
a::b->c.d;
void operator++(int);

И я ещё молчу про шаблоны. :) Синтаксис плюсов уже ничто не спасёт.

[Radagast]

если вспомнить про auto и (в будущем) static if, то средняя температура синтаксиса всё-таки движется в сторону улучшения

[leventov]

Температура синтаксиса — как энтропия, может только расти. Потому что новичкам учить (а старичкам поддерживать в памяти, что тоже непросто) надо по-любому ВСЕ.

Тут можно упомянуть smart pointers, rvalue references, variadic templates…

[Radagast]

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

[tbd]

главное чтобы не двигалось в сторону «больше слов, меньше дела»

вот из С++11
у меня сомнения проще это, или дополнительные нюансы синтаксиса…

struct A
{
 A() = default; 
 virtual ~A() = default; 
 A& operator =(const A&) = delete;
 A(const A&) = delete;
 A(int v) : {} 
 A(int a, int b): A(0) {}
};

[Radagast]

эти default и delete нужны для явного выражения намерений программиста, а раньше в этих местах могли скрываться грабли. Чем больше помощи от компилятора, тем лучше.

[Athari]

"= delete" и "= default" — это офигительно читаемый код относительно "= 0" — вытаскивания в код реализации чистой виртуальной функции запихиванием нуля в таблицу виртуальных вызовов. И "= delete" — уж однозначно прогресс над скрытием тех же методов (вместе с реализацией, кстати) в секции private, чтобы до них никто не дотянулся.

Движение в верном направлении.

[tbd]

Согласен это лучше чем было.
Но если я верно понимаю, остаётся и старый способ скрытия методов. То есть читая декларацию класса с вопросом «Можно ли объект копировать? Как?» вынужден проверять оба сценария. Отсюда и сомнения. Тут проще, там сложнее. А вместе как? (вопрос риторический, реальное использование покажет что к чему)

Вот auto + decltype это да. Действительно существенно упрощают синтаксис.

[cblp]

А что вам не нравится в

while (*s1++ = *s2++); char* c1, c2;

? Это же не С++, а С какой-то. Причём первый — переоптимизированный С. Вам не нравится, что в С++ осталась эта возможность?

[Athari]

Код while (*s1++ = *s2++); и подобный ему я видел столько раз, что уверен, что подобные конструкции нельзя не понимать, однако читаемым, сходу понимаемым назвать его весьма сложно. (Хотя конкретно эту строчку понять легко, потому что её все знают наизусть, ведь она — о ужас! — из книжек.)

Код char* c1, c2; — это частый источник ошибок (у новичков — очень частый). Почему половина типа задаётся слева, в общем куске кода, а половина — справа, индивидуально для каждой переменной? Я не могу этого понять. Разработчики того же шарпа от этой порочной практики ушли.

Разумеется, обратная совместимость… Если такой код появляется, он остаётся навсегда. Не все могут, как разработчики питона, всё переписать и долгие годы надеяться на светлое будущее, что весь код в мире перепишут. :)