Здравствуйте, Cyberax, Вы писали:

KP>>Если говорить именно в том ключе, то не хватает исключительно Карго. Всего остального вобщем-то хватает для фактически всего.
C>Карго бесполезен без модулей. С модулями его можно будет заколхозить и без всякого стандарта.

Примеры Conan, vcpkg, Hunter, cget, Buckaroo показывают, что построить управление зависимостями для C++ проектов без модулей в самом языке не проблема.
Главный камень преткновения здесь -- это наличие единой, де-факто и де-юре стандартной системы сборки. CMake становится де-факто стандартом, но еще не де-юре.

Здравствуйте, AeroSun, Вы писали:

AS>boost по большей части уже и не нужен, только asio пока ещё требуется (но это ненадолго) — уже есть либы попроще, полегковеснее, с классным интерфейсом, с великолепным перформансом, но без бездумного метапрограммирования.

Назови эти либы, пожалуйста.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Went, Вы писали:

W>>С другой стороны вещей, которые облегчают ежедневное кодирование, после прорыва С++11 я как-то не замечаю.

S>А библиотек для каких вещей не хватает?
Я же писал ровно обратное — библиотек море и они по мере развития стандарта стремятся к совершенству. Я говорю про средства языка, которые бы позволяли писать кратко и емко там, где сейчас приходится городить огород, или которые бы позволяли избегать ошибок и непредвиденных ситуаций. 11-ый стандарт дал нам лямбды, авто, range-for. А дальше... кроме полиморфных лямбд я не могу найти вещей, которые бы меня мотивировали переходить на новые стандарты.

вам даже structure binding в 11 завезли ? круто

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

Здравствуйте, Went, Вы писали:

S>>А библиотек для каких вещей не хватает?
W>Я же писал ровно обратное — библиотек море и они по мере развития стандарта стремятся к совершенству.

Простите, не правильно были восприняты ваши слова.

Здравствуйте, reversecode, Вы писали:

R>перебирать и критиковать легче чем придумывать и изобретать
Да хотелок у меня выше крыши, я время от времени "озаряю" ими форум. Понятно, что всего в язык не вместишь, я даже и не критикую — у меня не тот уровень квалификации, чтобы выносить взвешенные оценки. Я просто удивляюсь. 11-ый стандарт мне как бальзам зашел, я его понял и захотел еще до того, как его начали внедрять. А после этого вести с полей вызывают у меня преимущественно недоумение.

к 11 много накипело за много лет
если держать изменения еще десяток лет, то к какому нибудь C++35 тоже был бы прорывным
а так катают по чуть чуть в течении нескольких лет
поэтому новшества не так заметны

Здравствуйте, Went, Вы писали:

W>11-ый стандарт мне как бальзам зашел, я его понял и захотел еще до того, как его начали внедрять. А после этого вести с полей вызывают у меня преимущественно недоумение.

Объективности ради: на каждом следующем стандарте писать удобнее. На 14-ом удобнее, чем на 11-ом. Например, нормальный auto для функций завезли.

А на 17-ом удобнее, чем на 14-ом. Те же if constexpr, structured binding, вывод типов для шаблонов, объявление переменных в if-ах и switch-ах, [[nodiscard]].

Вроде везде по чуть-чуть, но когда приходится с 17-го в 11-й возвращаться, то уже ломает.

Здравствуйте, so5team, Вы писали:

W>>11-ый стандарт мне как бальзам зашел, я его понял и захотел еще до того, как его начали внедрять. А после этого вести с полей вызывают у меня преимущественно недоумение.
S>Объективности ради: на каждом следующем стандарте писать удобнее. На 14-ом удобнее, чем на 11-ом. Например, нормальный auto для функций завезли.
S>А на 17-ом удобнее, чем на 14-ом. Те же if constexpr, structured binding, вывод типов для шаблонов, объявление переменных в if-ах и switch-ах, [[nodiscard]].
S>Вроде везде по чуть-чуть, но когда приходится с 17-го в 11-й возвращаться, то уже ломает.
Да, может быть.

Здравствуйте, so5team, Вы писали:

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

S>Так что если вам лично не хватает в C++ библиотек для решения каких-то ваших прикладных задач, то могли бы вы перечислить, чего лично вам не хватает?

Ну тогда что мы обсуждаем раз сторонние библиотеки существуют?
Тогда чем занимается комитет, что расширяет стандарт для библиотеки? Ну там всякие any, options, filesystem, thread и т.д. И ещё планируют короутины, asio, ranges, и т.д.
Дураки-с однако, да? Ведь оно всё было и есть в сторонних библиотеках.

Здравствуйте, savitar, Вы писали:

S>Назови эти либы, пожалуйста.

A ты вбей в поиске на github — будешь удивлён.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, AeroSun, Вы писали:

AS>>только asio пока ещё требуется (но это ненадолго)

S>А что будет взамен, когда это "ненадолго" пройдет?

То же, что и с остальными бустовскими — более качественная и легковесная альтернатива с приятным интерфейсом. Возможно и по перформансу будет гораздо лучше, так как в текущем виде boost::asio надо разобрать от корки до корки, чтобы не убить производительность на ровном месте и минимизировать фрагментацию памяти.

Здравствуйте, AeroSun, Вы писали:

S>>Так что если вам лично не хватает в C++ библиотек для решения каких-то ваших прикладных задач, то могли бы вы перечислить, чего лично вам не хватает?

AS>Ну тогда что мы обсуждаем раз сторонние библиотеки существуют?
AS>Тогда чем занимается комитет, что расширяет стандарт для библиотеки? Ну там всякие any, options, filesystem, thread и т.д. И ещё планируют короутины, asio, ranges, и т.д.
AS>Дураки-с однако, да? Ведь оно всё было и есть в сторонних библиотеках.

Есть ощущение, что вы занимаетесь демагогией вместо конструктивного разговора.

Но если это не так, то:

* нормальной стандартной библиотеки у C++, по сути, никогда и не было. В древнем C++ была только stdlib из C и iostreams, в C++98 добавили STL. Более-менее нормальный вид стандартная библиотека C++ начала принимать только в C++11, но и здесь еще работать и работать для того, чтобы stdlib в C++ хотя бы сравнялась с тем, что есть в стандартных библиотеках других языков. Работа комитета в этом направлении ведется и достаточно успешно (с учетом всевозможных факторов);

* какова бы не была стандартная библиотека всегда будут области, для которых в стандартной библиотеке ничего не будет. И вряд ли должно быть в принципе. Пример: реализация клиента для MQTT и для Kafka. Такие области будут покрываться только сторонними библиотеками.

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

Исходя из этого вы можете перечислить библиотеки, которых вам лично в C++ не хватает для решения ваших прикладных задач?

Здравствуйте, AeroSun, Вы писали:

S>>А что будет взамен, когда это "ненадолго" пройдет?

AS>То же, что и с остальными бустовскими — более качественная и легковесная альтернатива с приятным интерфейсом. Возможно и по перформансу будет гораздо лучше, так как в текущем виде boost::asio надо разобрать от корки до корки, чтобы не убить производительность на ровном месте и минимизировать фрагментацию памяти.

И кто же это? Он сейчас уже есть или должен появится в светлом и счастливом будущем?

По поводу производительности Asio могли бы более предметно раскрыть тему? Или поделится ссылками на разбор проблем с производительностью Asio.

там для памяти свой аллокатор во весь асио воткнуть можно

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

Здравствуйте, AeroSun, Вы писали:

AS>Здравствуйте, savitar, Вы писали:

S>>Назови эти либы, пожалуйста.

AS>A ты вбей в поиске на github — будешь удивлён.

libev libevent ? есть свои недостатки

Здравствуйте, Cyberax, Вы писали:

C>Transactional Memory без железной поддержки не имеет смысла. Железная поддержка как-то не возникает всё и перспективы на несколько лет туманны.
А что не так с железной поддержкой в интел процессорах?

ИМХО, Transactional Memory не в manged языках c JIT малоприменима.

_>1. Рефлексия (в смысле статической интроспекции) — самая необходимая вещь в C++, которая сделает ненужной огромный кусок Boost'а.
_>3. Генерация кода на этапе компиляции (от банальной генерации по строке до метаклассов)

Для этого можно использовать внешние инструменты. https://github.com/foonathan/cppast, LibTooling.

Здравствуйте, AndrewJD, Вы писали:

C>>Transactional Memory без железной поддержки не имеет смысла. Железная поддержка как-то не возникает всё и перспективы на несколько лет туманны.
AJD>А что не так с железной поддержкой в интел процессорах?
"Она сломалась" (с)

Сначала реально сломалась в первых поколениях Haswell (вызывала жёсткие падения), потом оказалась удобным каналом для Spectre/Meltdown. И есть подозрения, что это только начало. Так что на Amazon AWS, например, сейчас оно доступно только на голых железках.

AJD>ИМХО, Transactional Memory не в manged языках c JIT малоприменима.
Применима, её уже использовали в ядре для оптимизации CAS-секций, например.

Здравствуйте, AeroSun, Вы писали:

S>>Назови эти либы, пожалуйста.
AS>A ты вбей в поиске на github — будешь удивлён.
Возможно. Но хотелось услышать конкретные названия и реальный опыт использования.