LINUX.ORG.RU

Стандарт C++20 утверждён

 


2

10

https://www.reddit.com/r/cpp/comments/f47x4o/202002_prague_iso_c_committee_trip_report_c20_is/

Желающие могут попробовать написать новость.

По виду std::format больше похож на fmt, чем на boost::format, что не может не радовать.

Небольшой обзор есть в статье на Хабре: https://m.habr.com/ru/company/yandex/blog/488588/ от Антона Полухина.

★★★★★

Последнее исправление: grem (всего исправлений: 1)

Ответ на: комментарий от eao197

Что вам мешает написать ...

То, что писать очевидные вещи смысла не вижу. Самый сок в том, что ты понял, о чём я говорю(даже пример лучший подобрал, чем сборка и запуск автотестов), но почему-то продолжаешь шланговать

Встречный вопрос: ...
Ну так перестаньте задавать встречные вопросы

С удовольствием, вот только тебя контролировать я не могу. И я всё ещё жду ответа на вопрос, какое отношение к проблеме долгой сборки имеет вот это:

ни доки курить, ни думать, ни обмениваться информацией с кем-то еще

DllMain
()
Ответ на: комментарий от eao197

Где-то слышал, что иногда дольше не столько компиляция идёт, сколько непосредственно линковка. Особенно если всё на шаблонах.

Но в той же blitz++ заявляют, что она такая быстрая именно из-за применения шаблонов.

gcc и clang с каждой версией собираются всё дольше и дольше :(

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

Где-то слышал, что иногда дольше не столько компиляция идёт, сколько непосредственно линковка. Особенно если всё на шаблонах.

Вот что g++ 7.4 на одном из тестов, с которым в последние дни приходилось работать, говорит посредством -ftime-report:

 phase setup             :   0.01 ( 0%) usr   0.01 ( 0%) sys   0.03 ( 0%) wall    1386 kB ( 0%) ggc
 phase parsing           :   3.82 (27%) usr   1.23 (53%) sys   5.06 (31%) wall  327615 kB (46%) ggc
 phase lang. deferred    :   1.82 (13%) usr   0.44 (19%) sys   2.26 (14%) wall  159077 kB (22%) ggc
 phase opt and generate  :   8.45 (60%) usr   0.66 (28%) sys   9.11 (55%) wall  221135 kB (31%) ggc
...
 TOTAL                 :  14.10             2.34            16.46             709224 kB

Тут и Asio, и fmtlib, и catch2. Всего больше 124KLOC.

Т.е. парсинг всего лишь треть времени отнимает.

gcc и clang с каждой версией собираются всё дольше и дольше :(

Зато сообщения об ошибках все лучше и толковее.

eao197 ★★★★★
()
Ответ на: комментарий от grem

Это как раз таки нормально: больше кода, больше функционала -> дольше собираются.

zamazan4ik ★★
()
Ответ на: комментарий от DllMain

То, что писать очевидные вещи смысла не вижу.

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

Самый сок в том

Самый сок в том, что я не хочу выдумывать чем вы или kawai_neko занимаетесь. Мне интересна информация о вас.

Вот вы чем таким занимаетесь, что компиляция в течении 5 минут снижает вашу продуктивность?

С удовольствием, вот только тебя контролировать я не могу.

И не пытайтесь. Проконтролируйсте себя, если сможете.

Итак, поскольку правила вы сами пытаетесь устанавливать в разговоре, то жду ответа на давно заданный вопрос вместо встречных вопросов.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

то, что очевидно лично вам, может быть совсем неочевидно другому человеку

Всё так. Но если для тебя неочевидны обсуждаемые вещи - о чём ты вообще пытаешься здесь спорить? Ну и я не зря о приведённом тобой примере написал - ты прекрасно понял мою мысль

я не хочу выдумывать чем вы или kawai_neko занимаетесь

Просто для протокола - речь не обо мне или ещё о ком-то

Итак

ответа от тебя не будет. Ну и ладно

DllMain
()
Ответ на: комментарий от DllMain

Но если для тебя неочевидны обсуждаемые вещи - о чём ты вообще пытаешься здесь спорить?

Молодой человек, как вам не надоедает демонстрировать собственное тугоумие? Я с вами не спорю. Если бы вы могли думать, то заметили бы это. Просто пытаюсь выяснить то, что мне интересно.

Просто для протокола - речь не обо мне

Т.е. вы попытались донести до меня свою точку зрения, но теперь оказывается, что речь не о вас. Замечаетельно, только непонятно, зачем вы отнимаете мое и свое время.

ответа от тебя не будет.

Вовсе нет. Как только, так сразу. Дело за вами.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

как вам не надоедает демонстрировать собственное тугоумие?

Ну ты же демонстрируешь, а я что - рыжий что-ли?

Я с вами не спорю. Просто пытаюсь выяснить то, что мне интересно

Да нет, именно что споришь. Ибо ты давно уже всё выяснил - я тебе в третий раз напомню о твоём примере с формами Qt, на котором ты спалился

вы попытались донести до меня свою точку зрения, но теперь оказывается, что речь не о вас

Да, речь о точке зрения, если так будет яснее. Внезапно, не так ли? Хотя, возможно для тебя единственным критерием является личность оратора. Но это лол

только непонятно, зачем вы отнимаете мое время

Меня не сильно интересует, насколько ты занятой человек. Если бы у тебя не было времени пофлудить здесь - ты просто этого не делал бы. Но ты все ещё здесь. Как-то это подозрительно

Как только, так сразу

Это в палату мер и весов надо. Эталон шлангования, на мой взгляд

DllMain
()
Ответ на: комментарий от eao197

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

anonymous
()
Ответ на: комментарий от DllMain

Но ты все ещё здесь. Как-то это подозрительно

Вам русским по черному было сказано: «Просто пытаюсь выяснить то, что мне интересно.»

Но теперь уже понятно, что выяснить что-нибудь у вас не представляется возможным.

Дабы вы не бросались больше какашками (а на другое вы явно не способны), проясню про «ни доки курить, ни думать, ни обмениваться информацией с кем-то еще».

К проблеме долгой сборки это не имеет отношение. Это «отношение» вы сами выдумали в силу особенностей своего мышления.

Зато имеет самое непосредственное отношение к продуктивности программиста. Если в вашем случае (как и в случае kawai_neko) вы не знаете, насколько сильно сказывается на продуктивности программиста изучение документации, продумывание проектных решений (и не только), взаимодействие с коллегами/заказчиками, то тогда, вероятно, ваша продуктивность напрямую зависит от скорости компиляции.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Зато имеет самое непосредственное отношение к продуктивности программиста. Если в вашем случае (как и в случае kawai_neko) вы не знаете, насколько сильно сказывается на продуктивности программиста изучение документации, продумывание проектных решений (и не только), взаимодействие с коллегами/заказчиками, то тогда, вероятно, ваша продуктивность напрямую зависит от скорости компиляции.

Ты просто до сих пор заблуждаешься, что пишешь сложный, нужный и полезный софт. Несложно углубиться в проектирование, когда единственный заказчик - это ты сам и пара товарищей. Действительно, какая разница, сколько будет компилироваться это «не нужно». И даже неудачные проектные решения не приведут ни к какому заметному для мира эффекту, разве что ты расстроишься немного. У крупного бизнеса и софт несравненно сложнее, и пользователей миллионы, а а не полтора калеки.

anonymous
()
Ответ на: комментарий от eao197

Кстати, а зачем в приличных фирмах закупают хорошие компы для сотрудников, если большую часть времени нужно думать о вечном, обсуждать что-то с коллегами, проектировать, медитировать и предаваться форумным баталиям, наблюдая за неторопливым процессом сборки?

Почему в успешных фирмах используются продуктивные средства разработки, а автор пары никому не известных библиотечек топит за обратное?

anonymous
()
Ответ на: комментарий от DllMain

Меня не сильно интересует, насколько ты занятой человек. Если бы у тебя не было времени пофлудить здесь - ты просто этого не делал бы. Но ты все ещё здесь. Как-то это подозрительно

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

anonymous
()
Ответ на: комментарий от anonymous

Сборка ведет к осознанию неизбежного.

тоже неплохо…

anonymous
()
Ответ на: комментарий от anonymous

в успешных фирмах используются продуктивные средства разработки

так и что в итоге? Какие средства разработки продуктивные?

seiken ★★★★★
()

Суть новости в том, что теперь вместо 10 лет на изучение цепепе потребуется 15 лет :-) Как минимум :-)

Если не изменяет память, то в некой книжке про дизайн и эволюцию заявлялось, что цепепе не задумывался в качестве всеобъемлющего средства, как, например, Лисп :-) Но тогда, видимо, автор и не предполагал, что будет такой вот стандарт 2020 :-) Сколько там теперь страниц будет? :-) Тысячи 3? :-) Интересно, кто это все будет испольовать, и, главное, зачем? :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

теперь вместо 10 лет на изучение цепепе потребуется 15 лет

и за это время выйдет еще две-три-четыре редакции стандарта.

ахиллесу никогда не догнать черепаху.

olelookoe ★★☆
()
Ответ на: комментарий от trex6

А ведь «книга» гораздо больше похоже на n-word, чем «негр». Я бы посмотрел на это шоу: «Эта книга мне понравилась гораздо больше той» ((:

Даже в каком-нибудь Брюсселе негритянские ребятки охреневали и оборачивались от таких пассажей.

anonymous
()
Ответ на: комментарий от anonymous

По моим ощущениям, при общении на неанглийском языке местные просто не обращают внимания.

Я же просто привык не использовать n-word ни в английском, ни в русском, чтобы упростить модель.

trex6 ★★★★★
()
Ответ на: комментарий от trex6

По моим ощущениям, при общении на неанглийском языке местные просто не обращают внимания.

А вы проведите эксперимент с «книгой», это будут уже не ощущения, а эмпирическое знание. Я провёл, было интересно – ещё как обращают.

Я же просто привык не использовать n-word ни в английском, ни в русском, чтобы упростить модель.

Понятно. Просто, интеллигенция местами пытается быть святее Папы Римского. Табуируют тех же «негров» в русском языке. «Чёрный» (если уж калькировать с английского до упора) по-русски гораздо хуже всегда было, по-моему. Википедия говорит, что не только в русском, кстати: «The Dutch word neger was considered to be a neutral term, but is now considered offensive by some, whilst others regard ‘zwarte’ (black) as offensive»

anonymous
()
Ответ на: комментарий от anonymous

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

А Лисп задумывался, да не подфартило. :D

anonymous
()
Ответ на: комментарий от anonymous

Почему в успешных фирмах используются продуктивные средства разработки, а автор пары никому не известных библиотечек топит за обратное?

Ну ты скажи ещё, что в успешных фирмах нет цепепе!

По сабжу, да, долгая компиляция раздражает, и да, плюсисты к этому привыкши и не компиляют на каждый чих, а когда компиляют, не смотрят в выхлоп мэйка, а переключаются на что-то. Такая вот у нас проф деформация, некоторые даже пытаются выставить это фичей. У нас как и у динуксоедов стокгольмский синдром :-)

filosofia
()
Ответ на: комментарий от eao197

Если вы будете оставаться в рамках подмножества C++98, то и тормозов при компиляции у вас не будет.

O_o

Разве в новых стандартах появились фичи, существенно замедляющите компиляцию? Наоборот, появились способы ее ускорить.

annulen ★★★★★
()
Ответ на: комментарий от anonymous

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

Я вам больше скажу «negro» – это и есть «черный» на испанском, от которого оно и произошло..

Сейчас всех нацменов принято называть People of Color – «цветные», проще говоря. Вот это, по мне, так гораздо более оскорбительно.

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от anonymous

Сколько там теперь страниц будет? :-) Тысячи 3? :-) Интересно, кто это все будет испольовать,

разработчики компиляторов

и, главное, зачем?

для разработки компиляторов

grem ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Сколько там теперь страниц будет? :-) Тысячи 3?

Сейчас не очень удачный момент в истории цпп: идет накопление фич – экстенсивное развитие. Лет через 10 будет очередь интенсивного развития, когда все устаревшее будет объявлено устаревшим и будут использовать некое современное подмножество языка.

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от annulen

Неправильно выразился. Подзабыл, что навороченный шаблонный код начали массово писать еще на C++98. Подразумевалось «код в стиле Си с классами». Такой реально сейчас компилируется влет, недавно удалось на собственном опыте убедится, был несколько удивлен.

Разве в новых стандартах появились фичи, существенно замедляющите компиляцию?

Скорее новые стандарты делают какие-то вещи более простыми в использовании, поэтому их начинают применять чаще, что сказывается на времени компиляции. То же метапрограммирование на современном C++ проще, так что даже я его стал регулярноо использовать. Плюс constexpr-функции.

Так что по ощущениям, компиляция C++17 проекта с constexpr, variadic templates, fold expressions, structured binding, активным использованием лямбд, [[nodiscard]] и всего такого, длится подольше.

Наоборот, появились способы ее ускорить.

Например?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Например?

Например, используя constexpr-функции вместо шаблонного ада. Хотя я согласен с аргументом, что простота использования склоняет к (преждевременной?) оптимизации там, где раньше было влом

annulen ★★★★★
()
Ответ на: комментарий от eao197

Вообще имхо неправильно говорить о «замедлении» компиляции, если в новых программах работа из рантайма переносится на стадию компиляции - еще бы она от этого не замедлилась)

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от annulen

Вообще имхо неправильно говорить о «замедлении» компиляции

Ну вообще-то это замедление ощущается даже на одном и том же C++ом коде. Скажем, полный билд С++14 библиотеки посредством clang-5 занимает 19m 55s, а clang-9 – 22m 20s.

А так да, согласен. Неправильно сравнивать скорость компиляции кода, который написан в разных стилях с использованием разных языковых возможностей.

eao197 ★★★★★
()
Ответ на: комментарий от annulen

constexpr-функции вместо шаблонного ада

Оба Тьюринг-полные, заодно NP-полные. И еще, как известно, у Тьюринг-полных языков есть «проблема останова». Успехов в оптимизации бесконечного цикла и в доказательстве N = NP, хотя бы теоретически.

anonymous
()
Ответ на: комментарий от anonymous

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

annulen ★★★★★
()
Ответ на: комментарий от annulen

И чем отличается «практически значимый код» от «попытки изнасиловать компилятор»?

anonymous
()
Ответ на: комментарий от annulen

NP ты свои вообще не по делу приплел

компилятору не надо генерировать кучу промежуточных классов

Думаю, проблема не в генерации промежуточных классов.

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

anonymous
()
Ответ на: комментарий от Im_not_a_robot

Лол :-) Начав прямо сейчас, через 10 лет пионэр всё ещё не будет готов писать на цепепе что-то реальное :-) Лол :-) Оно и сейчас, чтобы получить работу на какие-нибудь 200к в качестве цепепе пейсателя, нужно быть задротом каких свет не видывал :-) Оно и понятно, прочитав тонны книг с ахинеей про стандарты программирования на цепепе, всякие там паттерны и гуд коде стайл, правила 3, правила 5 и прочее прочее, неволей можно получить степень задротства :-) И т.н. тим лиды проверяют знания этой ахинеи у соискателей :-) Теперь вот можно будет ожидать тонны руководств о том, как нужно концепты составлять и модули варить :-) А тим лиды то как рады :-) Лол :-)

anonymous
()

Стандарт C++20 утверждён

Лютое 4.2. Договорились только послать драфт на утверждение.

anonymous
()
Ответ на: комментарий от anonymous

Ну, кто-то должен поддерживать старый код. Как без знания языка-то? :-)

dave ★★★★★
()
Ответ на: комментарий от anonymous

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

dave ★★★★★
()
Ответ на: комментарий от dave

А так да, занудного Страуструпа замучаешься дочитывать. Скорее всего, уже пятое издание сочиняет своего нетленного талмуда. Кроме страуструпов есть ещё саттеры, майерсы, александрески, и влиссидесы с джосаттисами :-) Причем, их труды описывают лишь сам цепепе и возможные трюки с ним :-) Даже после таких героических многолетних изучений, пади потом вспомни километровое выражение из какой-нибудь std::chrono без подсказки :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

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

Тем не менее, у C++ есть свое очарование. Код получается относительно быстрым, а иногда очень быстрым, даже стремительным по сравнению с другими языками. Практически полная независимость от Мозиллы, Микрософта, Оракла, IBM, всяких там сенатов и прочих палат лордов. Есть замечательные IDE, такие как Visual Studio, XCode, Qt Creator и куча-куча других. Огромное множество платформ. Довольно много еще осталось программистов со знанием C++. Много софта написано на этом языке, а переписывать этот софт никто не собирается.

К примеру, Раст этим похвастаться, ну, никак не может. У Ады свои тараканы. Так что, все еще так неоднозначно.

dave ★★★★★
()
Ответ на: комментарий от eao197

Про систему сборки. Можно пойти от обратного. Сделать её на базе полного ЯП, в рамках которого выразить DSL сборки. Есть языки, специально ориентированные под DSL такие как руби и котлин (и даже хаскель), но и на прочих высокоуровневых языках можно сваять АПИ, упрощающее описание проекта почти до уровня специализированного языка описания. Единственный минус такого подхода в том, что практически нереально сделать вменяемый инструментарий для правки сборочных файлов, так как даже простейшую задачу добавления файла в сборку по нажатии кнопки add file в ide непонятно каким кодом реализовать (а что если список файлов в проекте скачивается с инета в процессе сборки или еще каким-то непонятным образом формируется). Вот и получается, что стоит иметь 2 вида сборок. В виде описания, в котором робот может легко разобраться и в виде полного языка для случаев, когда нужно нечто необычное. Ну еще можно быть чудиком, который везде пихает сборку на языке, так как она в принципе более универсальная и со всеми задачами справится.

q0tw4 ★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Вся фигня в том, что С++20 страдает от тех же самых проблем, что и раст - никто не хочет использовать новое в реальных проектах. Все равно придется сидеть ждать хотя бы 2026, чтоб можно было смело на него обновляться. А если ты готов писать на С++20 сейчас, то что тебе мешает сразу поставить раст и забыть как страшный сон про совместимость с С++98 и С?

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

никто не хочет использовать новое в реальных проектах

Гы-гы. Не нужно говорить от имени всех. И не нужно путать «не хочет» и «не может».

Мир C++ настолько сегментирован, что для многих уже сейчас C++14 – это минимальная планка. И многих уже C++17 не смущает. А кто-то сидит на фичах из новых стандартов еще до официального принятия этих самых стандартов (например, судя по рассказам Полухина, в Yandex.Taxi новые фичи C++ сразу идут в дело).

Но кто-то себе и полноценный C++11 пока позволить не может.

А если ты готов писать на С++20 сейчас, то что тебе мешает сразу поставить раст и забыть как страшный сон про совместимость с С++98 и С?

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

Это из очевидного.

Из менее очевидного: далеко не все возбуждаются от слова Rust и от переспективы делать что-то на этом самом Rust-е. При всех своих достоинствах у Rust-а есть и фатальные недостатки. Начиная от корявого синтаксиса, заканчивая упоротыми фанатами, способными загнобить кого угодно, даже тех, кто сделал очень многое для популяризации этого самого Rust-а.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

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

Так это же один из основных факторов: большое и здоровое коммьюнити. Куда обращаться с вопросами, кто будет писать книги, руководства и статьи о языке? Кто будет клепать инструменты для языка и программистов на этом языке?

Как раз люди из интернета.

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

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.