Хочу поделиться с вами радостной новостью: теперь мы можем влиять на развитие C++! Под «мы» я имею в виду всех российских программистов, работающих с C++.
Но обо всем по порядку.
Рабочая группа по стандартизации C++
Язык программирования C++ развивается не стихийно. Его развитие контролирует международная организация ISO/IEC, а точнее, рабочая группа внутри этой организации ISO/IEC JTC1/SC22/WG21 C++. В её обязанности входит рассмотрение предложений по улучшению языка и стандартной библиотеки, голосование по предложениям и написание коротких отзывов по ним (почему предложение не прошло голосование, что именно не понравилось в предложении и т. д.). Причём большую часть предложений, как правило, вносят сами же члены комитета.
Зачем писать предложения и модернизировать C++
Ради славы и денег :) А ещё ради того, чтобы писать код было удобнее и работало всё быстрее.
Начнём с простоты написания кода. Чем больше отличных решений будет внутри стандартной библиотеки, тем меньше велосипедов надо будет изобретать для типовых задач. Раньше не было std::thread — и всем приходилось писать свои классы для кроссплатформенной работы с потоками. Раньше не было std::array — и мало кто знал как вернуть массив из функции. std::atomic избавил людей от необходимости опускаться до ассемблерного кода или до использования специфичных для компилятора расширений.
Теперь о быстродействии. Можно зафиксировать в стандарте наиболее оптимальные решения, либо добавить новые возможности, ускоряющие код «из коробки». Например rvalue-references позволили ускорить некоторые приложения, не меняя пользовательский код. std::string с недавнего времени обзавёлся возможностью хранить небольшие строки без динамических аллокаций памяти, что также положительно повлияло на производительность приложений.
Ну а теперь о славе и деньгах. Представьте диалог при приёме на работу:
— Вы работали с компонентом стандартной библиотеки std:: что-то-там?
— Да, это я придумал std:: что-то-там и занимался его продвижением в стандарт C++.
— Вы приняты!
При чём тут Яндекс
C++ является одним из основных языков разработки в Яндексе. Недавно мы подумали, что хорошо бы иметь больший контроль над таким важным для нас инструментом. Так мы начали копать в сторону создания рабочей группы по C++. Цели были амбициозные: разобраться в том, как всё устроено в комитете по стандартизации C++, создать рабочую группу из людей, которым данная тема близка, дать возможность российским разработчикам влиять на развитие языка, получить возможность переносить наши удачные разработки в стандарт и т.д.
Так сотрудники Яндекса копали, копали и случайно докопались до меня, который к тому моменту уже работал в Яндексе.
Как вам, возможно, известно, в свободное от работы время я занимаюсь разработкой библиотеки Boost, активно помогаю людям по всему миру с написанием предложений по улучшению стандарта, имею несколько собственных предложений по улучшению стандарта C++, находящихся в рассмотрении.
— Стоп, стоп, стоп! — заметит тут читатель. — Если предложения по C++ можно принимать и без Яндекса, зачем нам Яндекс?
Всё очень просто. Вы можете написать предложение по улучшению языка C++, но есть несколько нюансов.
- Нужно быть сильно «в теме» и знать, что именно писать в предложении, чтобы не пришлось его десять раз переписывать.
- Вам придется либо самому оказаться на заседании WG21, либо найти человека, который поедет на заседание комитета в Америке или Европе и будет отстаивать там ваше предложение и отвечать на вопросы.
- Некоторые удачные предложения были приняты с перевесом в один голос, так что неплохо иметь союзников в комитете.
- На заседаниях порой «не хватает рук». Если в заседаниях будут участвовать представители Яндекса, можно будет либо рассмотреть больше заявок, либо подробнее расписать авторам предложений, что необходимо доработать.
Именно с этими проблемами мы и должны будем помогать. Помимо меня, группой будет руководить Александр Фокин, который руководит одной из команд, разрабатывающих Поиск, и активно помогает в модернизации кодовой базы и внедрении в рабочую практику возможностей новых стандартов C++.
Как и когда это будет работать
В данный момент мы в самом начале пути. Мы создали рабочую группу (РГ21) на основе сотрудников Яндекса, группа является национальной зеркальной рабочей группой ISO/IEC JTC1/SC22/WG21 C++.
Нам еще необходимо доразобраться в бюрократических вопросах, познакомиться с членами WG21, поучаствовать в нескольких заседаниях и влиться в рабочий процесс. Вдобавок на носу C++17, и все сейчас загружены подготовкой финальной версии стандарта. Но если все пойдет по плану, то в декабре этого года мы уже начнем помогать российским разработчикам с предложениями по развитию языка C++.
Что бы мы добавили в стандарт в первую очередь
Нас очень интересует стандартизация плоских контейнеров, наподобие boost::container::flat_set и boost::container::flat_map. Это сложная работа и проводить её надо аккуратно, консультируясь с ведущими разработчиками подобных контейнеров.
Ещё у нас есть ряд компонентов, которые широко используются в нашем коде и которые будут полезны множеству разработчиков. Первое, что приходит на ум, это класс для вывода stack trace. Чтобы включить наши компоненты в стандарт, надо много чего: перевести наименования в нижний регистр, оторвать от класса компоненты, которых нет в стандарте, добавить интеграцию с классическими потоками ввода/вывода, выложить в открытый доступ, получить отзывы и т. д.
Мы также надеемся, что начнётся работа над предложениями по Dynamic Library Load — P0275R0 и P0276R0. Раньше подобные предложения отклонялись из-за их сложности, но в этот раз получилось свести изменения в ядре языка к минимуму.
Также есть идеи по крайне проблемным для продвижения вещам, таким как интерфейсные классы, доступ к полям структур по индексу и базовая рефлексия.
Куда писать, если есть предложения
Мы создали рассылку cpp-proposals@yandex-team.ru — свои предложения, идеи и пожелания присылайте на нее. Постараемся ответить как минимум на самые интересные и многообещающие. Как максимум — на все.
Вместо итогов
Мы тут подготовили небольшой опросник, чтобы оценить объём предстоящих работ и заинтересованность людей.
| 3% (8) |
У меня есть (скоро будут) готовые предложения и прототипы для включения в стандарт C++, их надо представить на заседании. |
| 13% (30) |
У меня есть идеи для включения в стандарт C++, нужно писать предложение/прототипы, сам не справлюсь (ну или лень). |
| 11% (26) |
У меня есть пачка мелких замечаний и однострочных исправлений к стандарту. |
| 88% (209) |
Хочу класс для вывода stack trace :) |
Проголосовало 237 человек. Воздержалось 295 человек.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (124)
xander27
24.05.2016 11:43+13Немного офф.топ: а как вы в компании и другие читатели, пишущие на C++, относитесь к rust? Есть вероятность применения, в ближайшем будущем, в продакшене вместо C++?
stepancheg
24.05.2016 12:40+5Я не могу говорить за всю компанию, моё мнение такое: Rust можно будет использовать в продакшне сразу после того, как в Rust сделают IDE и доделают инкрементальную компиляцию. Это случится, я думаю, приблизительно в течение года-двух. До того, как эти фичи будут реализованы, Rust проблематично использовать в больших долгоживущих проектах. После того, как эти фичи будут реализованы, C++ можно будет постепенно закапывать.
Впрочем, есть небольшой шанс, что в C++ добавят основные фичи Rust (в первую очередь borrowed pointers; сделают модули вместо препроцессора и доделают «концепты»), и Rust станет не нужен.TargetSan
24.05.2016 13:00Не добавят. Lifetimes начисто противоречат как минимум copy by default в C++, к тому же придётся мучительно аннотировать весь код чтобы это работало. Концепты в Rust есть уже сейчас в виде Traits & Trait impls. Модули добавят хорошо если к 20-му году. Препроцессор останется с нами навсегда во имя совместимости. Аналога же Cargo вообще не предвидится в обозримом будущем.
Короче, единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода. Плюс несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
stepancheg
24.05.2016 13:32+5> Lifetimes начисто противоречат как минимум copy by default в C++
Не вижу противоречий. Поясни?
> к тому же придётся мучительно аннотировать весь код чтобы это работало
Не мучительнее, чем в Rust.
> Препроцессор останется с нами навсегда во имя совместимости.
Пусть остаётся. Но пользоваться им будет не обязательно.
> Аналога же Cargo вообще не предвидится в обозримом будущем.
Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
Это утверждение справедливо для любого другого языка программирования.
> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.TargetSan
24.05.2016 14:14+1>> Lifetimes начисто противоречат как минимум copy by default в C++
> Не вижу противоречий. Поясни?
Может, не совсем правильно выразил свою мысль. Попробую написать более развёрнуто.
Во-первых, тот самый copy by default. В С++ «первичны» именно байтики, составляющие значение, а не само значение, с его семантикой и смысловой нагрузкой. Выражается это в том, что без дополнительных телодвижений значение любого типа будет банально копироваться. Делая «умный указатель», надо не забыть в обязательном порядке или запретить копирование, или правильно его обработать. Как следствие — можно схлопотать implicit copy, после чего дважды уничтожение одного и того же значения. Напротив, в Rust происходит move by default. Т.е. хочешь сделать копию — явно опиши как, а если не нужно — не будет лишних ошибок.
Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
В общем, чисто теоретически можно написать для С++ стороннюю утилиту, которая будет выполнять проверки на время жизни. Но геморроя будет слишком много. Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт. Как результат — низкоуровневые уши торчат наружу. В то же время в Rust семантика значения первична на уровне с его представлением.
>> к тому же придётся мучительно аннотировать весь код чтобы это работало
> Не мучительнее, чем в Rust.
Компилятор обругает за каждое пропущенное место. Как поступать с пропусками аннотаций в С++ — неясно.
>> Препроцессор останется с нами навсегда во имя совместимости.
> Пусть остаётся. Но пользоваться им будет не обязательно.
Макро-константы. Их валом до сих пор.
>> Аналога же Cargo вообще не предвидится в обозримом будущем.
> Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
Верно. Однако IDE вы, например, хотите. Как инструмент, конечно. Стандартизировать IDE нет никакого смысла. Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
>> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
> Это утверждение справедливо для любого другого языка программирования.
В принципе да. Конкретно этот мой аргумент наверное несостоятелен. Генератора биндингов из Python в Ruby я не видел :)
>> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
> C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Короче, в С++ накопилось слишком много проблем, часть из них не имеют адекватного решения без поломки обратной совместимости.stepancheg
24.05.2016 15:22+1> Во-первых, тот самый copy by default.
Не вижу, как это противоречит lifetimes. В Rust, кстати, для POD-типов copy by default тоже бывает, и lifetimes в нём работают.
> Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
Не вижу, как это противоречит lifetimes.
> В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
Очевидно, ввести новый синтаксис. Можно прямо синтаксис из rust заимствовать.
> В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
Всё, что написано в текущем синтаксисе, не проверять. Если lifetimes присутствуют, то проверять. Сделать warning в компиляторе — указатели без lifetime. Сделать опцию сделать такой warning ошибкой.
> Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт… Как результат — низкоуровневые уши торчат наружу
Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
> Макро-константы. Их валом до сих пор.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
> Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
> Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.TargetSan
24.05.2016 16:06lifetimes
Я не могу, конечно, строго доказать, что в С++ в принципе нельзя добавить borrow checker. Но количество проблем и нестыковок будет просто зашкаливать. Не вижу смысла получать в стандарт ещё +200 страниц. Он и так толстый.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
Поживём-увидим.
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
А вот мне хотелось бы писать на С++ удобно. А не танцевать с бубном, выбирая из нескольких вариантов подключить тот же Google Test. Java как бы тоже не хипстерная вещь, однако же есть Maven и его репозитории.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
ответил здесь: https://habrahabr.ru/company/yandex/blog/301514/#comment_9623684
snizovtsev
24.05.2016 16:19+1Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
Как обеспечить обратную совместимости при введении в язык lifetimes? Ведь это фича, которая сильно сужает множество принимаемых компилятором программ, а не наоборот. А нужно чтобы старый код продолжал работать.
Получается поддержка lifetimes — вирусная фича, которая не позволит внутри себя использовать старый код. Такое мы проходили — называется constexpr. Его ввели в C++11, но продолжают активно допиливать в C++14, C++17. А STL так и не допилили, поэтому придумали Sprout. При этом из нового синтаксиса там лишь одно ключевое слово, что явно будет мало для lifetimes.
Так что если оно и будет в C++, то не раньше C++30. И это оптимистичная оценка :) Вот концепты старый код не ломают, а их уже лет 10 принять не могут.
stepancheg
24.05.2016 17:12> Как обеспечить обратную совместимости при введении в язык lifetimes?
Сделать указание lifetimes опциональным.
khim
24.05.2016 15:44+5Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Не подходит. Есть куча мест, где GC нельзя использовать. По разным причинам. Так что Golang на замену C/C++ не претендует и никогда не претендовал. D отпадает по той же причине (практически он без GC работать может, практически — стандартная библиотека идёт лесом). Rust — теоретически может. Посмотрим как оно выйдет на практике.TargetSan
24.05.2016 15:57-1По поводу GC. Я специально написал "жёсткое байтоложество", т.е. максимальный уровень управления ресурсами. Для перемалывания тонн данных — нет. Писать прикладные утилиты — вполне. Rust в этом пункте не упомянул специально.
Gorthauer87
24.05.2016 13:07+1Сейчас уже пара полу IDEшек на расте есть, тем же vs code можно очень активно пользоваться. Главная проблема тут в отсутствии дебага. Насчет компиляции, то можно и нужно разделять большие проекты на маленькие модули, тогда и компилируется быстро и архитектура лучше.
Можно вообще мысленно сделать соответствие класс на с++ == модуль на расте. Благо пишутся они элементарно.
Насчет плюсов не уверен, что это поможет. Слишком большую телегу из старых костылей с собой таскать приходится.
stepancheg
24.05.2016 13:26-4> Сейчас уже пара полу IDEшек на расте есть, тем же vs code можно очень активно пользоваться
Эти «IDEшки» пока больше похожи на редакторы с подсветкой синтаксиса, чем на полноценные инструменты для работы с большой кодовой базой.
> Главная проблема тут в отсутствии дебага
Нет, главная проблема в том, что в этих «IDEшках» отсутствуют примерно 99% фич, которые присутствуют в современных IDE типа JetBrains IDEA.
А дебаг редко нужен, только в очень специфичных случаях. Тесты надо писать.
> Насчет компиляции, то можно и нужно разделять большие проекты на маленькие модули, тогда и компилируется быстро и архитектура лучше
Сомнительный совет — переписать код, чтобы исправить тормоза компилятора.
В любом случае, этот совет в общем случае не работает. Далеко не все проекты распиливаются на осмысленные маленькие модули.
iroln
24.05.2016 17:07+1Вы думаете, полноценная IDE для Rust появится за год-два? Я думаю, что не появится. Без коммерческой поддержки компаний, заинтересованных в языке, не появится. JetBrains, на сколько я знаю, ничего такого пока не планируют.
stepancheg
24.05.2016 17:16+2> Вы думаете, полноценная IDE для Rust появится за год-два?
Если сделают IDE server, который делает 80% работы, то достаточно хорошая IDE появится быстро.
> Без коммерческой поддержки компаний, заинтересованных в языке, не появится. JetBrains, на сколько я знаю, ничего такого пока не планируют.
Сегодня не планируют, завтра запланируют. Для typescript сделали, для groovy сделали, и для rust сделают.Gorthauer87
24.05.2016 18:54+1Есть уже Racer, который как раз этим и занимается, есть куча linter'ов и аналогичных тулзов. Но сделать Racer полноценным инструментом рефакторинга не так то и просто, на самом деле.
zbase32
24.05.2016 12:41-2Непонятно ещё, почему у яндекса нет своего ЯИСТ, не хватает амбиций чтоли? Не плодят велосипедов? А чё Мозилла плодит, дураки чтоли?
stepancheg
24.05.2016 12:42Mozilla — некоммерческая компания, она не ставить целью зарабатывание денег, поэтому может позволить себе такие проекты.
yomayo
24.05.2016 14:14+1Хочу быть Мозилой! Хочу быть некоммерческой организацией, у которой нет заботушки о хлебе насущном, хочу позволить себе заниматься проектами типа Rust! Очень хочу, честное слово…
antoshkka
24.05.2016 12:57+1Кто сказал что нет…
Просто мы не изобретаем ненужных велосипедов общего пользования, наш язык заточен под очень специфичные нужды и будет интересен разве что конкурентам. Он даже на язык программирования не особо похож, очень много позаимствовано из визуального программирования.zbase32
24.05.2016 13:02-1Понятно, спасибо.
Но всё же языки и платформы появляются чаще, чем можно обосновать догмой про велосипеды, значит, это выгодно, тому же гуглу с его golang.khim
24.05.2016 13:33+2Гугл создал Go не потому, что он Гугл, а потому что там работает Роб Пайк. И то язык получился достаточно специфическим и назвать его «языком общего назначения», скорее нельзя.
Создавать языки — это легко и весело, а вот создавать языки, которые могли бы встать в один ряд с «большими» языками типа C++ — это тяжело.
TargetSan
24.05.2016 13:03Я бы очень даже за. Даже всерьёз начал переделывать один микросервис, просто посмотреть как пойдёт. Остановили генерация биндингов (непонятно что делать с кучей констант, заданных макросами; автора макро-констант убить мало) и zeroing drops — т.е. объект с деструктором распухает, а мне это сильно мешало делать обёртки над хендлами.
mwambanatanga
24.05.2016 12:10-3Хочу поделиться с вами радостной новостью: теперь мы можем влиять на развитие C++! Под «мы» я имею в виду всех российских программистов, работающих с C++.
То есть Яндекс будет влиять на развитие C++, прикрываясь именем и интересами всех российских программистов. Отчего же мне не радостно совсем?antoshkka
24.05.2016 12:22+16Как-то вы видите всё в мрачном свете. Давайте я распишу процесс поподробнее:
1) Вы хотите добавить в стандарт std:: что-то
2) Пишете proposal, мы вам помогаем (если хотите). Автором proposal являетесь Вы, ваше имя в нём стоит, Яндекс никак не упоминается.
3) Не можете поехать на заседание комитета сами — мы готовы представлять ваши интересы. Мы задаём вам кучу вопросов по предложению, слушаем ваши идеи и пожелания. Защищаем ваши интересы на заседании, отстаиваем ваши идеи. Если остальные члены комитета против — будем ловить их в свободное время и спрашивать что именно им не понравилось в предложении. Все их хотелки и пожелания — передаем вам, говорим как можно подправить proposal.
4) Повторяем процесс до тех пор пока proposal не примут или вам не надоест :)
И на этом всё. Если мы хотим добавить что-то своё, то процесс для нас такой же, как и для обычного программиста и нам надо goto 1).mwambanatanga
24.05.2016 13:34-3Да я всё вижу в мрачном свете. Я нигде не видел, чтобы российские программисты толпами просили Яндекс стать их представителем.
Можно ли миновать Яндекс в этом процессе? Если миновать нельзя, то всё печально. Если миновать можно, то не надо делать вид, что Яндекс представляет РФ. В любом случае, поводов для радости я не вижу.Evir
24.05.2016 13:46+5Не вижу поводов для мрачных мыслей.
Миновать Яндекс — можно. И да, никто не просил Яндекса стать представителем. Но Яндекс предлагает тем, у кого есть мысли по развитию C++ быть посредником по обсуждению в комитете этих самых мыслей — бесплатно и без смс.
Не так уж мало они при этом будут делать. Помогут с proposal, могут поехать на заседание и т.д. из комментария выше. Не так уж и мало, и ничего не прося взамен, кроме возможности попиариться.
Так что фиг с ними, пусть пиарятся.
NLO
24.05.2016 12:35НЛО прилетело и опубликовало эту надпись здесь
orcy
24.05.2016 12:54+3Или добавить в стандарт линковку через наши духовные скрепы, например. Но как я понял что это просто помощь в продвижении предложений в стандарт с нашими региональными особенностями: не всякий наш разработчик способный предложить улучшение языка сможет пройти все формальности включая присутствие на комитетах. Кроме того будет кто-то русскоязычный с кем можно проконсультироваться как правильно оформить само предложение.
zbase32
24.05.2016 12:58+2Упор только внутри вашей головы. А в заголовке обычный факт.
NLO
24.05.2016 14:43НЛО прилетело и опубликовало эту надпись здесь
zbase32
24.05.2016 14:51+2Вы не путайте поляны, если американцы не указывают на всех табличках, что это американская корпорация, это не значит, что корпорация перестала быть американской. Это значит, что для американцев Америка это дефолт-стейт. Полноценная страна в которой может быть создано вообще всё. Поэтому и указывать не надо. Как Москва для москвичей.
Если люди указали, что в российском Яндексе российские программисты представляют Россию — это просто факт. Эта ситуация даже не требует вашего околофашистского термина «ватник». Страны пока не отменили, следовательно, и заслуги стран как совокупность заслуг граждан — это констатация.
Вы не с Украины часом?vlad72
25.05.2016 17:31Я тоже думаю, что ограничение только «российскими программистами» бессмысленно. А там, где люди видят бессмысленность, возникают подозрительные подозрения ))
vlad72
24.05.2016 13:04-2Сейчас модно каждой компании свой язык создавать…
zbase32
24.05.2016 13:05-7Не путайте айти-метрополию и какую-то там Россию…
vlad72
25.05.2016 17:27-5Ну, Россия не такая уж маленькая в смысле и финансов и рынка для Яндекса. Могли бы и свое что-то запилить. Не все же капусту рубить…
Создали бы новую открытую ветку С++ и управляли бы ею на благо себе и человечеству.khim
25.05.2016 17:59+1Спасибо, но… спасибо не надо.
Я в своё время общался с преподавателями информатики, использующими ЛогоМиры, у которых диалект Лого — локализован. И у преподавателей по их поводу — одни матерные слова: так как английские ЛогоМиры понимают только английские слова, русские — только русские, а немецкие — только немецкие, то дети, участвующие во всякого рада программах «международного обмена» не могут обмениваться своими творениями!
Долгое время люди просто использовали старый добрый LogoWriter (и не рассказывали детям про локализованные ключевые слова, благо нелокализованные он тоже понимал), но после повсеместного перехода на XP пришлось от этого отказаться (совместимость XP с DOS уж очень паршивая).
И это — дети! Профессиональные программисты, уверяю вас, общаются между собой несколько чаще…vlad72
25.05.2016 19:44-1Я не говорю про локализацию )) Речь про то, сильная софт-компания может сделать для себя или новый язык, или его ветку, или фреймворк. Принцип такой — надо и есть ресурс? делай сам!
ditu
25.05.2016 20:54-2Вам же говорили — только в метрополии люди мыслят так, как вы предлагаете. Там Эгрегор, а здесь так, вторичность.
yomayo
24.05.2016 13:55+2Насколько мне известно, в комитете по стандартизации C++ Россию представляли Евгений Александрович Зуев и компания «Интерстрон». Как-то упустил момент передачи эстафетной палочки. «Яндекс» как-то сотрудничает в этом плане с «Интерстроном»?
antoshkka
27.05.2016 15:29Представители Росстандарта нам ответили что «Давно живет в Швейцарии<...> Про наш комитет и подкомитет он знает, но связей с нами не поддерживает.»
От себя могу добавить, что не нашёл его контактов в ISO Global Directory, так что активной деятельности он не ведёт.
snizovtsev
24.05.2016 14:11+2Первое, что приходит на ум, это класс для вывода stack trace
Это плохое предложение. Даже игнорируя вопрос "а чем выбор нестандартных библиотек плох?", не всегда по скомпилированному бинарнику можно этот самый stack trace получить, в релизной сборке читай никогда. Получается этот класс пригоден только для отладки, а значит относится не к языку, а к инструментам разработки.
Правильный путь — использовать out-of-process breakpad (или альтернативу, которую я не знаю) и генерировать minidump-ы. Парсить стек можно уже спокойно на crashdump сервере в режиме оффлайн (с использованием debug symbols). Так мы минимизируем вероятность ошибки при диагностике ошибки и не загружаем основной процесс не его работой.
Что касается стектрейса в catch блоке — его получить нельзя, т.к. к моменту захода в catch стека уже нет. Генерировать стек в throw — огромный оверхед. Кроме того — что считать стеком dependent (rethrow) исключения? Но если почитать вуду c++ — то можно придумать решение. Для себя я как наиболее оптимальное придумал такой вариант — делать прослойку в стеке вызовов со специальной personality routine, которая отлавливает исключения в search phase и делает снапшот (minidump). Такую прослойку ставить в начало стека, где стоит catch-all обработчик. Получается, что в случае необработанного исключения мы и не падаем (с std::terminate), и стек трейс имеем. Могу подробнее написать об это статью :)
arteast
24.05.2016 15:30+1> не всегда по скомпилированному бинарнику можно этот самый stack trace получить, в релизной сборке читай никогда
При наличии в бинарнике async unwind tables вроде бы должно быть можно, не?
Статью — просим нижайше, очень интересная тема. И про breakpad, и про сбор стека в полете исключения.
У нас есть костыль, пишущий минидампы, на базе SEH-обработчика, но хотелось бы чего-то более C++ного и универсального. Если оно еще и под *nix сумеет асинхронные сигналы перехватывать и дампить (и давить потом, чтобы можно было как-то попытаться восстановиться) — вдвойне интересно
izvolov
24.05.2016 14:54+5Новость хорошая, сам бы с удовольствием посотрудничал.
Но… Смущает то, что раньше в Яндексе было всё печально с языком C++. Вы уже перешли массово хотя бы на C++11? Как поживаютya::strochkaиya::shtrochka?antoshkka
24.05.2016 17:29+2> Вы уже перешли массово хотя бы на C++11?
Конечно перешли.
> Как поживают ya::strochka и ya::shtrochka?
Наши внутренние библиотеки живы и активно развиваются, если вы об этом. Даже те, которые появилась до STL, во времена когда ещё свет не был отделён от тьмы, а мухи от котлет.
kukutz
24.05.2016 23:53+6> Как поживают ya::strochka и ya::shtrochka?
Как вы думаете, зачем эта рабочая группа была создана?
Конечно же, пропозал на std::Stroka уже отправлен!
</joke>
ditu
24.05.2016 16:54-3Интересно, зачем вообще развивать этот язык, может быть стоит оставить его в покое… и обратить своё внимание на Rust хотя бы.
drBasic
24.05.2016 18:33+3По прагматичным причинам в первую очередь. Например потому что браузер, в котором вы читаете это сообщение, написан на с++, и переписать его на Rust стоит миллионов человеко-дней, что довольно долго и ну очень дорого.
snizovtsev
24.05.2016 18:42+4С вами согласен, но пример получился не очень. Rust как раз и создавался, чтобы переписать кое-какой браузер :)
Gorthauer87
24.05.2016 18:58+3Тот день, когда с Серво получится написать здесь комментарий действительно будет важным днем в развитии браузеров. Но пока он еле еле в гитхаб научился логинится.
ditu
25.05.2016 17:34-1Для этого не надо развивать язык, достаточно заморозить стабильную версию и с ней жить, пока она ещё нужна. Поразительный консерватизм иногда наблюдается среди прогрессивного айти-сообщества.
svboobnov
02.06.2016 20:37Зря вы человеку минусов накидали. Сам Беорн Стровструп признался, что цпп мог быть и получше, но взлетело то, что сделали на коленке. А новый код было бы здорово на D или на Rust писать (авторы обоих языков говорят, что языки уже более-менее устаканились.
khim
02.06.2016 21:20D — это что-то мертворождённое, похоже. Вот, почитайте: Phobos (standard library) is deprecating features too quickly. Это месяц назад написано.
С++ уже где-то к 1990му году (то есть лет через 7-8 после создания) пришёл в состояние, когда устаревшие фичи поддерживались годами (а после выхода стандарта через 15 лет после создания языка — уже вообще почти ничего не удалялось).
Тут же… На дворе, на минуточку, 2016й год. Язык появился 15 лет назад. И он всё ещё позволяет себе менять стандартную библиотеку несовместимым образом? Это — клиника, извините.
На Rust же можно аккуратно так поглядывать. Посмотрим. Первые признаки обнадёживают, но пока с момента выхода версии 1.0 слишком мало времени прошло — год всего.svboobnov
02.06.2016 22:47Спасибо, интересно человек пишет.
И правда, до стабильности и обратной совместимости Java D не дотягивает, совсем.
svboobnov
02.06.2016 22:55Добавлю ещё, что вот у Lisp ов (и даже CommonLisp'ов) стандартных библиотек почти нету (языку больше 50 лет). А тот библиотечный код, который есть, совместим не со всеми реализациями CommonLisp. И ничего, живут люди.
У паскалистов (к коим и себя отношу) есть всего 2 реализации ObjectPascal: от Embarcadero и от сообщества FreePascal. Обе реализации несколько несовместимы, библиотеки перетряхиваются (порой очень основательно) у обеих реализаций, но люди пользуются, главное — прибить компилятор гвоздями к проекту.khim
03.06.2016 05:24Добавлю ещё, что вот у Lisp ов (и даже CommonLisp'ов) стандартных библиотек почти нету (языку больше 50 лет). А тот библиотечный код, который есть, совместим не со всеми реализациями CommonLisp. И ничего, живут люди.
Плохо живут. Энтузазисты — да, могут что-то такое на этом сваять. Но для больших проектов оно не подходит — никак.
Одно время проект GNU продвигал диалект лиспа под названием «GNU Ubiquitous Intelligent Language for Extensions». Ubiquitous, Карл! Результат? Его никто не использует. Когда в GDB засунули поддержку расширений на питоне Столлман (большой любитель Lisp'а, кстати) заставил сделать и поддержку Guile тоже — но кто про это, вообще, знает?
У паскалистов (к коим и себя отношу) есть всего 2 реализации ObjectPascal: от Embarcadero и от сообщества FreePascal. Обе реализации несколько несовместимы, библиотеки перетряхиваются (порой очень основательно) у обеих реализаций, но люди пользуются, главное — прибить компилятор гвоздями к проекту.
Это — из той же серии, что и PHP: кто-то когда-то начал использовать «славный» Turbo Pascal 7.0 на уроках в школе — и предпочитает «плакать, но есть кактус» уже многие годы. У D такой форы нету: для обучения программирования его не используют, на бесплатных хостингает его не ставят… нафиг с ним связываться?
NeoCode
24.05.2016 19:48+2Модули пробивайте в первую очередь. Любой ценой и любым способом в С++17. Без этого развитие языка зайдет в тупик очень скоро (уже заходит). Остальное подождет, а вот без модулей совсем печально.
EvgeniyRyzhkov
25.05.2016 09:27+1Это очень хорошо и для Яндекса как компании, что они вкладываются в поддержку C++ таким образом. В этом плане Яндекс довольно сильно проигрывает Google. Ведь у Google есть даже свои инструменты для C++, а у Яндекса (пока?) ничего такого нету. Будем надеяться, что появится со временем.
sermp
25.05.2016 14:57Кстати, на встрече в Казани будут представители Яндекса, с которыми можно будет поговорить о процессе стандартизации :)
MTonly
25.05.2016 16:18Было бы неплохо сделать объявление прототипов функций необязательным (хотя бы в случаях, когда прототипы и функции всё равно располагаются в одном и том же файле), а также сделать возможным без танцев с бубном использовать методы объектов в качестве функций обратного вызова, например, в WinAPI.
Sirikid
25.05.2016 16:27Если вы имеете ввиду прототипы методов, то их нельзя не объявлять из-за модификаторов доступа, а обычные функции и так можно без прототипов использовать.
MTonly
25.05.2016 16:41На моей памяти ещё относительно недавно (в пределах 2-3-х лет) функцию без прототипа удавалось использовать только в случае, если её определение располагалось выше функции, её вызывающей; если в этом плане что-то изменилось, то замечательно (кстати, какими средствами сборки это поддерживается?).
Sirikid
25.05.2016 20:31Извините, перепутал немного, функцию без прототипа вызвать действительно не получится, но методы можно. Думаю это для совместимости с C.
MTonly
25.05.2016 20:48Не вполне понятно, о какой совместимости вы говорите. Совместимость Си и C++ имеет место только в отношении компиляции Си-программ компилятором C++, но не наоборот.
antoshkka
25.05.2016 17:52+1> сделать возможным без танцев с бубном использовать методы объектов в качестве функций обратного вызова, например, в WinAPI
От такой фичи не отказались бы многие. Осталось придумать как её реализовать. У вас есть рабочий прототип или идея, как подобное воплотить в жизнь?MTonly
25.05.2016 18:15-3Реализация — дело разработчиков компиляторов/компоновщиков. Как пользователь языка я не вижу причин, почему нельзя прозрачно использовать метод как функцию обратного вызова (разные соглашения вызовов — это внутренняя кухня, которая не обязательно должна касаться пользователя).
RPG18
25.05.2016 18:27Как пользователь языка C++ вы должны знать про функции, указатели на функции, указатели на методы — это не указатели. Подробно написано в «C++. Священные знания: второе издание, исправленное» Стивена Дьюхерста.
MTonly
25.05.2016 20:29-3Как человек, программирующий на уровне хобби, я ничего никому не должен. По существу — на уровне синтаксиса вполне мог бы существовать синтаксический сахар, прозрачно превращающий одно в другое.
khim
25.05.2016 18:42+1разные соглашения вызовов — это внутренняя кухня, которая не обязательно должна касаться пользователя
Совершенно верно. Но она должна касаться составителя proposal'а. А то у вас пока предложение в стиле древнего анекдота.MTonly
25.05.2016 20:45-1Я ничего не предлагал. Просто сказал, что это было бы неплохо. Или вы скажете, что это было бы плохо? ;-)
khim
25.05.2016 18:29А что случилось с существующим proposal'ом?
Там основная проблема в том, что нужно где-то хранить дополнительные данные, в proposal'е идёт речь об «allocator that can provide executable memory».
Почему-то все считают, что этот proposal требует нарушения W^X и вообще ужас-ужас-ужас, но в реальности переносимая версия (работающая на POSIX — то есть реально более-менее везде, кроме Windows, LOL) делается тривиально.
Делаете служебную библиотечку, скажем с тысячей thunk'ов. У каждого из них — пара инструкций, загружающих данные и вызывающих std::function. Когда bound_function создаётся — один из них захватывается и в соответствующий std::function загружаются данные для вызова. Когда bound_function освобождаются — thunk поступает обратно «в распоряжение» соответствующией подсистемы. Если нужно больше, чем тысяча таких объектов — грузите ту же самую библиотеку ещё раз (про dlopen(RTLD_LOCAL) не забываем) и получаете ещё тысячу thunk'ов.
Делов-то.
Видимо просто никому особо не нужно или выигрыш не кажется особо ощутимым…antoshkka
25.05.2016 19:05Звучит хорошо. Осталось продумать:
* многопоточность — всё должно рабоатать в многопоточных приложениях и при том быстро
* embedded устройства — на них держать тысячи thunkov — непозволительная роскошь
* производительность — не стоит грузить библиотеки с dlopen(RTLD_LOCAL) за спиной пользователя; идеальный вариант — без динамических аллокаций и загрузки библиотек
* как понять когда bound_function освобождается?khim
25.05.2016 21:10* Насчёт работы в многопоточных приложениях и при том быстро — это как-нибудь потом: всегда можно развести локальные кеши и прочее — если возникнет потребность. Чем это отличается от
operator new, я извиняюсь?
* embedded устройства, которые были бы достаточно велики, чтобы позволить себе полную библиотеку C++ (влючая локализации и прочее), жёстко энфорсят W^X, но при это не могут позволить себе потратить 10-20KiB под загружаемую библиотеку? Это хде? Можно прописать в стандарте, что гарантируется обновременная работа не более «N» живых bound_function объектов и тем самым покрыть и embedded и системы без динамической аллокации памяти.
* Без динамических аллокаций и загрузки библиотек — это круто: придумаете как засунуть два байта в один (точнее восемь в четыре) — расскажите. Разработчики GNU C (где очень-очень похожая фича есть — но только в C) этого сделать не смогли, но, понятно, это не значит, что это в принципе невозможно.
Вообще код и данные во многих системах могут «жить» в разных местах, так что вариантов не так и много. Насчёт загрузки библиотек… почему когда банальныйprintfилиostreamэто делают это нормально, но когда это же будет делатьbound_function, то это пробелема?
* Не понял вопроса? Компилятор как-нибудь разберётся. Когда деструктор вызывается — это, вроде как, в других частях C++ описывается… довольно подробно.
khim
25.05.2016 21:49Вообще вы правы, конечно: сделать подобную штуку — это большая работа. Концептуально всё просто и не требуется никаких изменений, собственно, в компиляторе, однако под каждый компилятор (вернее каждый ABI) всё нужно делать отдельно (thunk'и ведь имеют «нестандартный» ABI: это не variadic функции, но какие они при этом получают аргументы на входе — одному богу ведомо… и вот эти аргументы, «не поцарапав» нужно передать дальше).
На ассемблере всё отлично делается, понятно (под все известные мне архитектуры), но — это реально куча работы. Плюс с не-POSIX платформами где «на отвяжись» (берите 128 «одновременно живущих» указателей — и ни в чём себе не отказывайте) не хочется делать, нужно разобраться. Хотя собственно скорее не «с платформами», а «с платформой»: Windows… У меня сейчас доступа к Windows нет и, честно говоря, связываться ней совершенно неохота — но понятно, что без Windows практического смысла в этой фиче не будет.
Или может вы знаете какие-нибудь другие «живые» не-POSIX платформы где энфорсится W^X? Если W^X не энфорсится (а это — почти весь «малый» эмбеддед), то проблем, в общем, гораздо меньше (хотя всякие Atmel'ы с их модифицированной гарвардской архитектурой, конечно, могут кровушки подвыпить).
Потому, собственно, я и не собираюсь это продвигать в качестве proposal'а: я реально оцениваю свои возможности. Как я уже говорил: концептуально — проблема яйца выеденного не стоят, но вот чтобы довести это до чего-то, что можно реально использовать — нужно несколько человеко-месяцев работы, я боюсь.
MTonly
26.05.2016 23:11-1Если человек-программист может создать функцию-обёртку, вызывающую нужный метод объекта, и передать указатель на эту функцию в качестве callback-функции, то, вероятно, компилятор (или, на худой конец, препроцессор) мог бы неявным образом делать что-то аналогичное автоматически.
khim
27.05.2016 13:15Человек-программист для этого где-то «прикапывает» указатель на сам объект. Передавая его через дополнительный параметр в «функцию-обёртку», делая глобальной переменной (если объект у вас один) и т.д. и т.п.
Как ваш «на худой процесс препроцессор» будет решать эту проблему — науке неведомо.
mmatrosov
25.05.2016 17:50> Мы создали рабочую группу (РГ21) на основе сотрудников Яндекса, группа является национальной зеркальной рабочей группойISO/IEC JTC1/SC22/WG21 C++.
Не могли бы вы уточнить, что конкретно это значит?encyclopedist
25.05.2016 21:00+3Помимо центрального (международного) комитета, в каждой стране может быть свой, национальный, комитет. (Его формальная роль такова: при принятии стандарта, сначала черновик рассылается в национальные комитеты, которые могут выдвинуть свои замечания и поправки, а также голосуют за черновик). (Эти все правила устанавливает организация ISO).
Так вот, Яндекс, судя по топику, создал российский национальный комитет, в который сейчас входят сотрудники Яндекса. Теоретически, в него может также войти любая другая компания.
Также, судя по топику, сотрудники Яндекса планирую участвовать в заседаниях международного комитета (где рассматриваются пропозалы по изменению стандарта, проходят 2-3 раза в год). Получат ли она там право голоса, я не знаю.
MTonly
26.05.2016 01:53+2Мы создали рассылку cpp-proposals@yandex-team.ru — свои предложения, идеи и пожелания присылайте на нее.
А почему выбрано такое архаичное и неудобное средство коммуникации, как список рассылки, а не форум? Использование издавна существующих списков рассылки ещё можно более-менее оправдать традициями (хотя вот даже CSSWG недавно решилась переместить новые обсуждения на баг-трекер на GitHub), но создавать в 2016 году новый список рассылки? %)
onto
30.05.2016 08:29+1Будет ли подсайт яндекса со списком присланных предложений, где можно будет проголосовать и обсудить предложения? Рассылка есть, но это сомнительной удобности решение, имхо.
antoshkka
01.06.2016 10:00Да, мы думаем об этом. Есть еще несколько организационных идей которые так же находятся в рассмотрении.
apro
>Dynamic Library Load
>стандартизация плоских контейнеров
>класс для вывода stack trace
И почему среди кучи разных сугубо специфических вещей не упоминается
то, что вызывает раздражение у каждого C++ программиста каждый божий день?
А именно — скорость компиляции. Бедный компилятор снова и снова парсит мегабайты
исходников. При этом существующие полуавтоматические решения для использования precompiled headers
вызывают еще большее раздражение, особенно в кросплатформенных проектах.
И главное и proposal есть для модулей, но конечно не в c++17, ведь сферические функции важнее.
Может стоит все-таки за модули побороться, а stack trace подождет?
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
antoshkka
> Может стоит все-таки за модули побороться, а stack trace подождет?
Есть отдельная подгруппа, занимающаяся модулями в комитете по стандартизации C++. Занимаются они модулями уже очень давно, они сильно «в теме» и с модулями множество проблем о которых мало кто задумывается:
* циклические зависимости
* линковка (в стандарт в данный момент вводится понятие module level linkage в дополнение к internal и external linkage. Вводить новое определение — очень сложно, необходимо проверить как оно взаимодействует со старыми определениями, нет ли конфликтов и прочего)
* макросы и как их экспортировать
* шаблоны и как их экспортировать из модулей. А если шаблон не проинстанцированный, как его экспортировать?
* typedef|using|constexpr и прочее
и т.д.
В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их экспериментальная поддержка. Необходимо это для того, чтобы найти и решить проблемы о которых не подумали на этапе проектирования. Поторопить тут никого не получится.
Вам может приглянуться эта библиотечка.
Это прототип, показывающий, что уже в C++14 можно определять содержимое структуры. Как правило подобные прототипы очень хорошо влияют на голосование по предложению, так что надеемся что особых проблем с доступом к полям структур по индексу не возникнет.
apro
>В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их
> экспериментальная поддержка
Если их == модули, то есть и даже не в одном:
http://clang.llvm.org/docs/Modules.html
https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/
>Поторопить тут никого не получится.
ИМХО, у людей работающих долго над чем-то, что не взлетает обычно
хорошо прокачено искуство объяснять как все сложно, но при этом
свежий вгляд от тех кто не испугался бывает им очень полезен.
>Вам может приглянуться эта библиотечка.
У меня уже есть решение основанное на парсинге с помощью libclang определения структур и
генерации метаинформации для работы с полями стуктуры в runtime.
ИМХО конечно, но в вашей библиотеке ведь даже название поля нельзя получить? Для сериализации
в json/xml это важно.
encyclopedist
Вы привели 2 реализации. В этом и была проблема — это 2 несовместимых подхода (главная разница — в вопросе, экспортировать ли макросы.) И потребовалось очень много времени, чтобы сторонники двух подходов договорились и пришли к единому мнению. Собственно, реализации итогового варианта вроде пока нет (хотя я не уверен, может быть Microsoft уже обновил реализацию)
snizovtsev
o_O вот это магия! Но как?!
antoshkka
Если очень вкратце:
* template <size_t> struct ubiq { template operator T(); };
* пробуем aggregate initialization для структуры: T { ubiq{}… }
* уменьшаем количество ubiq, первое собравшееся выражение подсказывает нам сколько полей в структуре
* правдами и неправдами вытаскиваем информацию о типе к которому преобразоввывался ubiq из оператора неявного приведения
* PROFIT: имеем количество полей внутри структуры и их типы
Обязательно постараюсь выступить на конференции и написать статью на эту тему: в коде намешано много интересных трюков и фишечек без которых работает всё плохо или не работает вообще.
6opoDuJIo
>>циклические зависимости
Звучит как «мы не будем добавлять наследование из-за проблем с возможных циклическим наследованием».
Стыдоба. Само предположение о необходимости циклической ссылки будет свидетельствовать о том, что ты что-то делаешь не так.
p.s. в C# с такой задачкой справляются. Справятся и тут.
TargetSan
Циклические зависимости вполне возможны. Модуль A может зависеть от B::bar, а модуль B — от A::foo. Ничего плохого в этом нет. Проблема разрулить такие зависимости в рамках отдельных строительных блоков, чтобы там циклов не было.
Хотя мне это конечно напоминает аргументацию за введение синтаксиса 'auto foo(...) -> ret_type' тем, что компилятор якобы должен сначала увидеть определение аргументов, чтобы вычислять на их основе тип результата.
khim
a<b>(c)может обозначать как «вычислиa < bи сравни результатс», так и «создай объект шаблонного типаa, параметрированногоbи передай ему в качестве параметраc» или «вызови функциюa, параметрированнуюbи передай ей в качестве параметраc»).И если компилятор ещё породит ошибку — это полбеды. А если он проинтерпретирует выражение не так, как того хотел программис?
В общем это — реальная проблема. Не столько для стандарта, сколько для разработчиков, впрочем. И да — с модулями то же самое.
RPG18
Подключил ccache и сборка сильно не беспокоит, а вот stack trace для ARM, x86, x86-64 мне куда полезнее.
apro
>Подключил ccache и сборка сильно не беспокоит, а вот stack trace для ARM, x86, x86-64 мне куда полезнее.
И как помогает ccache разработчику? Человеку, который отвечает за дистрибутив да, но современные
системы сборки и так собирают только измененные файлы, или имеется ввиду распределенный для нескольких разработчиков ccache или случай сборки сильно различающихся веток одного проекта?
При этом также следует учесть, что даже перекомпиляция одного файла используещего буст (без precompiled header) вполне может 10 секунд занимать на не слабом железе (i7/16 GB RAM/SSD),
конечно кэширование объектный файлов (ccache)
и распределение сборки по кластеру (distcc) в какой-то мере спасают положение, но не до конца.
У каждого из них есть свои недостатки, кэширование слабо поможет если изменение вызывает перекомпиляцию
нескольких файлов, а dictcc не вариант если расходы на передачу input/output компилятора по сети сравнимы
с временем компиляции.
>stack trace для ARM, x86, x86-64 мне куда полезнее
ИМХО, stacktrace вполне можно реализовать в виде общего интерфейса плюс реализация
для каждого компилятора/runtime, конечно удобно было иметь это в std::, но проблема решается,
а вот для времени компиляции одни костыли, проблему даже на 50% не решающие.
Gorthauer87
Мне кажется, что аналог cargo бы дал возможность обкатывать любые хотелки на кошках, иметь набор кроссплатформенных библиотек и не тащить всё вообще в std.
khim
Я наблюдал долгую компиляцию при использовании
boostа, но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно быстрее: распутывать всё это метопрограммирование — тяжёлая задача для компилятора, единственное решение — это нормальное метапрограммирование, а не то, что у C++.Тут, я боюсь, малой кровью не отделаться — нужно менять всю систему. Rust пока кажется неплохим вариантом — надо будет посмотреть как он развиваться будет.
apro
>Я надеюсь, вы это не под Windows меряете?
Linux, правда конечно от boost spirit другого сложно ожидать в плане времени компиляции.
>но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно >быстрее
>всё это метопрограммирование — тяжёлая задача для компилятора
Не согласен, да время компиляции одного объектного файла модули не изменят,
но мы же говорим о сборке проекта целиком и вот тут как раз модули помогут,
т.к.
>всё это метопрограммирование — тяжёлая задача для компилятора
и поэтому решать ее несколько раз это полный бред.
Решил один раз загрузив CPU на 100% и отъев несколько гигабайт RAM, так закэшируй результат.
Те же 10 секунд превращаются в 2 секунды, когда засунешь boost includes в отдельный header
файл и превратишь его в precompiled.
encyclopedist
Попробуйте Spirit X3, он компилируется несравненно быстрее.
metopa
А что не так с метапрограммированием в C++?
khim
Тем что метапрограммирование происходит не на C++, собственно.
RPG18
Преимущественно ccache использую на билд под CI.
Да же у Google в Breakpad этого не получилось
khim
Так он может, в зависимости от настроек компилятора, компилироваться 3-4 секунды — или минуту. Это, конечно, не Swift с его знаменитыми 12 часами, но всё равно раздражает.ccache, к сожалению, не панацея. Причём дело не в заголовоных файлах и не в модулях. У нас в проекте есть такой простенький файл golden_output.cc с одной функцией:Gorthauer87
В swift'е долгая компиляция это баги, да и Apple готова если что ломать обратную совместимость, а в плюсах это уже by design, увы.
arteast
Я поддерживаю этот крик души (тот редкий случай, когда я был полностью согласен с Гитлером)), но направлен он явно не по адресу. Модули были представлены на рассмотрение комитету, и тот решил их не включать в C++17 (как, собственно, и остальное самое интересное, что было представлено). Национальные представители не могут «заставить» CoreWG принять другое решение. Лучшее, на что мы можем надеяться в ближайшей перспективе — это принятие модулей как TS.
Если рассмотреть вопрос модулей с более практической точки зрения, то
а) ничто не мешает их использовать уже сейчас, хоть они и не в стандарте — VS2015U1 уже умеет, clang вроде бы тоже что-то выкатывал.
б) если бы они даже вошли в стандарт, то это не значит, что их вдруг стало бы можно использовать — нужна поддержка компиляторами, и нужна поддержка библиотеками.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном C++11, и то не везде. C++14 еще не стало популярным (даже нет полной поддержки в MSVS), не говоря уж о C++17.
Что касается тех фич, про которые говорится в статье:
— Dynamic Library Load — не вижу большого смысла вносить это в стандарт. Фича, имхо, достаточно редкая, и она полностью закрывается замечательными библиотеками, скрывающими кишки от пользователя, типа того же Boost.DLL. Атрибут [[visible]] в стандарте при том полностью поддерживаю (я не очень понял, как там модули решат проблему с dllimport, но это отдельный разговор).
— стандартизация плоских контейнеров — это тоже решено библиотеками, но эта фича очень востребована, так что оно в стандарте вполне уместно
— класс для вывода stack trace — очень специфическая фича, и есть библиотеки в помощь. Если идти в сторону стандартизации, то было бы лучше стандартизировать ABI для описаний функций; это, к сожалению, утопично, а заставить разработчиков компиляторов поддерживать единого API над своими ABI — тоже выход.
— интерфейсы — интересно, но пока не очень ясно, чем это принципиально отличается от ABC. Меня бы больше порадовала возможность описывать в публичных заголовках классы частично (только публичные функции), если внешним потребителям не требуется знать структуру класса в памяти. Сейчас либо приходится вываливать на всеобщее обозрение кишки класса, либо делать ABC, либо колбасить Pimpl или что-то похожее.
— доступ к полям структур по индексу и базовая рефлексия — архинужно, хотя бы на уровне проитерироваться по полям структуры и узнать их имена. Но на это уже есть как минимум 2 документа, которые давно в работе. Какой-то из двух должен в конце концов дойти до стандарта.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала. Лучше, на мой взгляд, было бы доделать модули и сделать наконец какой-нибудь нормальный dependency manager, и выносить функционал в отдельные самодостаточные библиотечки. При этом можно сделать какой-нибудь особый namespace для «официальных» библиотек типа «isocpp/» и не менять процедуру стандартизации «официальных» модулей; пусть также они сначала пишутся и обсуждаются в рабочей группе, потом идут в LibraryWG и там монстры и корифеи их доводят до идеала. А вот потом, вместо того, чтобы увеличивать и без того огромный документ под названием C++ standard, каждый модуль может оставаться независимым мини-стандартом по типу TS, и у него будет одна реализация в одном месте вместо кучи независимых под каждый компилятор. 3 из 5 фич, упомянутых в статье, можно было бы вынести в такие вот библиотеки.
antoshkka
Прошло всего 4 года, а стандарт уже подхватили некоторые основные игроки, новые проекты и open-source. Это молниеносная скорость для enterprise, это очень хорошая скорость для open-source.
Насколько я помню, у них и C99 пока не поддерживается полностью. У этой компании свои цели развития, мне не известные.
Был сделан выбор в пользу современных тенденций и требований рынка. C#, Java, Python умеют очень многое из коробки и людям это нравится по мнигим причинам, например:
* В некоторых компаниях запрещены библиотеки кроме стандартной (нужен variant/flat_set/shared_library? Пиши сам с нуля, в компании <имя практически любой ООО работающей с деньгами> спец требования к безопасности.)
* Когда пишешь что-то с чем раньше не встречался, хочется использовать что-то идущее вместе с языком, а не выбирать пару дней из N библиотек.
* Документации на стандартную библиотеку всегда больше чем на сторонние.
Одна реализация — это адище для разработчика библиотеки и медленное внесение исправлений под ошибки компиляторов. Посмотрите на количество #ifdef/#elif в коде Boost для каких-либо старых компонент… а ведь это при том, что Boost недавно отказался поддерживать некоторые античные компиляторы.
P.S.: мы тоже хотим модули :) Очень хотим!
TargetSan
Java, project Jigsaw. С точностью до наоборот — распиливание стандартного рантайма на несколько кусков поменьше, для тех кому не надо всё.
Также, никто не тянет Spring, Hibernate, Entity Framework в стандартные библиотеки.
По поводу документации — гораздо легче воспринимать маленькие самодостаточные компоненты.
Зато для пользователей библиотеки адищем является целая пачка её разновидностей. А большое кол-во директив условной компиляции — следствие зоопарка компиляторов в прошлом.
arteast
> Прошло всего 4 года, а стандарт уже подхватили некоторые основные игроки, новые проекты и open-source.
А хочется еще быстрее и еще больше ) Хочется async await, а приходится использовать gcc 4.7, в котором и C++11 не до конца допилен. Грустные реалии промышленного программирования.
> Насколько я помню, у них и C99 пока не поддерживается полностью.
В 2013 версии с C99 все стало гораздо лучше (хотя может быть все еще не полностью, утверждать не буду).
> Был сделан выбор в пользу современных тенденций и требований рынка…
Я имел в виду сделать некий набор официальных библиотек, которые бы стандартизировались по тем же принципам, что сейчас идет стандартизация в общий стандарт, и поддерживались производителями компиляторов. Соответственно — проблемы с безопасностью не больше, чем при использовании стандартной библиотеки компилятора (пишут те же люди); нет проблемы с выбором среди N библиотек — есть 1 официальная; документация на такие библиотеки тоже будет хорошей.
Из плюсов — меньше времени будет тратиться на добавление фич и их модификацию (я имею в виду спецификацию фичи — нет привязки к 3-годичному циклу общего стандарта); качество реализации каждой фичи будет выше (ибо не N реализаций от N команд, а 1 реализация от N команд; и пользователей кода соответственно X, а не X/N); баги в реализации будут фикситься быстрее (нет привязки к релизу следующей версии компилятора).
Из минусов — да, больше #ifdef/костылей под разные компиляторы (хотя буст в этом смысле не показатель — он пытается поддерживать старые компиляторы, а здесь производитель компилятора может просто не заявлять поддержку старых версий — как это и делается сейчас в стандартной библиотеке); меньше давление на производителя компилятора по поддержке новых стандартных библиотек (хотя и сейчас это их не останавливает — case in point MSVC и C99/expression SFINAE). На примере Boost.DLL — вроде бы самодостаточный модуль без каких-либо зависимостей (и он вполне может пройти все круги стандартизации за пару лет), но в лучшем случае это попадет в C++20; и даже после этого мы будем ждать, пока msvs/gcc/clang/icc реализуют эту часть стандарта у себя и выпустят очередные релизы, или использовать полифиллы из того же Boost. А можно было бы выпустить TS где-нибудь к 18 году и подождать, пока кто-то один/два из производителей накропает одну реализацию, которая скорее всего заработает со всеми остальными.