По виду std::format больше похож на fmt

Так ведь предложение на std::format и писал, если не ошибаюсь, автор fmt. Как раз взяв за основу fmt.

Да, я о таком слышал, и хорошо, что приняли именно его. Только похоже, что оставили только питоновский «синтаксис» с {}, синтаксис printf (с %), судя по сторонней документации не видно, ну и ладно.

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

Можно отказываться от fmtlib или там свои нюансы?

Мы уже года 4 используем fmt, надобности с printf-синтаксисе ни разу не возникло. Так что, действительно, «ну и ладно».

Тут вот есть обзор std::format: https://www.bfilipek.com/2020/02/extra-format-cpp20.html, так что те, кто «в танке», могут ознакомится.

Так ведь предложение на std::format и писал, если не ошибаюсь, автор fmt. Как раз взяв за основу fmt.

О, тогда очень годно.

Так ведь предложение на std::format и писал, если не ошибаюсь, автор fmt. Как раз взяв за основу fmt.

Да, там подмножество.

А вообще, поздравляю всех причастных. По практической применимости таких крупных обновлений стандарта не было с C++11.

Модули-то добавили? А пакетный менеджер?

Модули-то добавили?

Да.

А пакетный менеджер?

Нет.

Ну и, как обычно в C++, добавление такое, что без 0.7 не разберешься (а 0.5 будет мало).

Желающие могут посмотреть эту презентацию: https://meetingcpp.com/mcpp/slides/2019/modules-the-beginners-guide-meetingcpp2019.pdf

шо, с С++98 можно переходить?

Теперь еще год ждать, пока все эти фичи появятся в релизных версиях компиляторов?

Бесполезная какая-то лажа получается. Им бы сборку унифицировать, потому что сборка кода на цпп — ад и израиль.

Бесполезная какая-то лажа получается.

Время покажет. Пока что для нас, как для разработчиков библиотек, самая большая проблема – это то, что в ближайшие лет 10 нам на модули не перейти. Т.к. тогда наши либы не смогут использовать те, кто вынужден оставаться на C++11/14/17.

Им бы сборку унифицировать, потому что сборка кода на цпп — ад и израиль.

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

только autotools, только хардкор

Я уже не помню, когда видел именно плюсовый проект с autotools. Ну а сишники пусть надрачивают, им привычно.

Теперь еще год ждать, пока все эти фичи появятся в релизных версиях компиляторов?

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

Давеча видел autotools, который используется только для сборки Debian-пакета для проекта на Meson’е.

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

Я вот чего не понимаю, кстати, но может ты мне прояснишь. Почему все системы сборки для сишных или плюсовых проектов имеют тьюринг-полный язык? Зачем это? Почему нельзя написать простой DSL для описания зависимостей и целей сборки, который покрывал бы 99% сценариев, а для остального, так и быть, сделать поддержку внешних скриптов? Ну вот как Cabal для хацкелла или Cargo для хруста.

Серьезно?

Теперь большая часть низкоуровневых C-трюков гарантированно работает в C++.

Новая фича - хорошо забытая старая фича. А вообще, старый Си лучше новых двух (++, кто понял)

Также комитет согласился приоритизировать предложения по направлениям: Pattern matching

Ну нифига себе, неужто дождемся. Глухо же было, не считая странного PoC от Бьярна.

Если использовал нотацию printf, то придётся переделать как минимум на нотацию из python. Подробнее не смотрел.

Другое дело, что gcc 9.2 и clang 9.1 о нём ничего не знает даже с флагом -std=c++2a

загулил этот ваш std::format…

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

А вот это с хабра приводит в офигение

Сейчас идёт работа над включением в стандарт BLAS и LAPACK

Я вот чего не понимаю, кстати, но может ты мне прояснишь.

Могу попробовать. Причем как человек, который с 1995 по 2004-й сделал несколько собственных build-tool-ов для C++. Но не факт, что мое объяснение вас удовлетворит.

Почему все системы сборки для сишных или плюсовых проектов имеют тьюринг-полный язык? Зачем это?

Потому что в мире C++ всегда царил зоопарк компиляторов и их версий. И для того, чтобы собрать что-то больше чем одним компилятором (или хотя бы больше чем одной версией одного компилятора) приходилось (да и приходится) заморачиваться с проверкой кучи условий. Типа если компилятор gcc и мы под FreeBSD и еще если луна в такой-то фазе, то тогда нам нужна вот такая-то вот опция.

И тут оказывается, что учет всех этих особенностей гораздо проще вести на нормальном ЯП (будь то Python, Ruby или даже чудом выжившая жертва выкидыша в CMake), чем на каком-то декларативном DSL. Говорю об этом на собственном опыте, т.к. изначально тоже пытался обойтись декларативным DSL-ем.

Не используют, так как не реализовано в компиляторах. Используют fmt (его основу), потому что лёгкий. boost::format как альтернатива тащит за собой половину boost и парой заголовочных файлов в проект не утянешь.

Мне казалось что sprintf/snprintf используют, но да, форматирование вывода через std::cout та ещё радость, особенно если между спецификациями вывода чисел с плавающей точкой нужно переключать.

Почему нельзя написать простой DSL для описания зависимостей и целей сборки, который покрывал бы 99% сценариев, а для остального, так и быть, сделать поддержку внешних скриптов?

в meson же примерно так и есть, не? А вообще тогда встает вопрос портабельности этих самых скриптов.

Вашими либами и так никто не пользуется 😉.

Но, ок, не будем об этом.

https://www.youtube.com/watch?v=QuoKNZjr8_U

в meson же примерно так и есть, не?

Не.

https://gitlab.com/federicomenaquintero/bzip2/-/blob/master/meson.build

А вообще тогда встает вопрос портабельности этих самых скриптов.

Какой именно портабельности?

Вашими либами и так никто не пользуется 😉.

Есть ложь, есть наглая ложь, а есть 3.14здежь ЛОР-овский анонимусов.

https://www.reddit.com/r/cpp/comments/ev2obp/light_and_powerful_modern_webframework_for_c/fftgy9z/

https://news.ycombinator.com/item?id=21107379

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

Как часто такие особенности возникают? Потому что у большинства проектов, которые я видел, одна и та же копипаста на autoconf или cmake.

Такое ощущение, что практически постоянно. По крайней мере мы у себя постоянно что-то под if-ами делаем.

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

Между тем именно такие анонимные ссыкуны, которые боятся зарегистрироваться (потому что история их тупости будет зафиксирована) превратили LOR в редкостное по токсичности говно. В котором разве что метапроги и можно обсуждать.

Ай, гори-полыхай!

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

ЛОЛ, тот случай, когда язык настолько загромождённый и замороченный, что даже написать об этом новость - сложная инженерная задача, которую могут осилить полтора ЛОРовца. Так победим!

Групповое фото комитетчиков C++20 мне понравилось. Оно есть на хабре сегодня. Желаю им удачи!

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

Добавить флаги в зависимости от платформы можно в декларативном языке.

Я уже проходил этот путь. В конце-концов он ведет к появлению нормального ЯП с if-ами, подпрограммами и структурами данных.

Можете не верить, но если сами возьметесь сделать подобный DSL с поддержкой нескольких компиляторов на нескольких платформах (особенно если там еще и экзотика какая-нибудь будет), то скорее всего и сами к такому выводу придете.

Видишь ли в чём фигня. У других языков нет проблем с поддержкой нескольких платформ почему-то. Может проблема в нескольких компиляторах? Опять же, непонятно.

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

Во-первых, одна составляющая проблемы – это разные компиляторы со своими особенностями и придурями.

Во-вторых, некоторые языки сами по себе являются платформами.

Эх... Сегодня только писал

// C++17 has std::filesystem
string get_file_name(const string& full_path) {
    return full_path.substr(full_path.find_last_of("/\\") + 1);
}

Ура. 🎆🎆🎆 С++ – 💪🏿. Хейтеры 👊🏿👧🏾🖕🏿. 🚒👩🏿‍🚒👩🏿‍🚒👩🏿‍🚒 уже выехала к вам.

комитетчиков

Звучит почти как «гб’шников»

А вы какой системой сборки пользуетесь?

Во-первых, одна составляющая проблемы – это разные компиляторы со своими особенностями и придурями.

А много ли их осталось? Гцц, шланг и мсвц, остальные вроде сдохли. Первые два имеют одинаковые флаги и прочее. Но, в любом случае, запилить абстракцию над флагами — не рокет саенс. Хотя для начала на мсвц можно просто болт положить.

Во-вторых, некоторые языки сами по себе являются платформами.

Что ты имеешь ввиду?

Для своих проектов собственной, написанной на Ruby много лет назад.

Для заказчиков – как фишка ляжет.

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

А много ли их осталось?

Как минимум 4: gcc, clang, msvc, icc. Но вроде как есть и экзотика. Плюс даже у этих четырех разные версии с разными ключами.

Но когда эта котовасия начиналась было с десяток живых.

Хотя для начала на мсвц можно просто болт положить.

Ну да, ну да. Тут даже на MSVS2015 болт положить просто так не получается, не смотря на наличие MSVS2017 и MSVS2019, а кто-то еще вынужден сидеть на MSVS2011.

Но на LOR-е все просто: забить и нет проблем.

Что ты имеешь ввиду?

В свое время был афоризм по типу «Java – это не кроссплатформенный язык, это сама по себе платформа». Суть в том, что Java или C# – это эдакие песочницы, за пределы которых выходить никому не нужно.

Ну да, ну да. Тут даже на MSVS2015 болт положить просто так не получается, не смотря на наличие MSVS2017 и MSVS2019, а кто-то еще вынужден сидеть на MSVS2011.

Вот этого я тоже не понимаю. Кто мешает собирать код даже под старые системы новым компилятором? Вроде же обратную совместимость никто не ломает.

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