Корутины не осилили, сеть не осилили. Да сколько можно!? Где concurrency TS? Где Transactional memory? Зато типичный плюсовый надроч на мелочевку и микрооптимизации
Re[2]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, kaa.python, Вы писали:
KP>Корутины не осилили, сеть не осилили. Да сколько можно!? Где concurrency TS? Где Transactional memory? Зато типичный плюсовый надроч на мелочевку и микрооптимизации
modules, ranges, contracts, concepts — вполне себе крупные фишки. У тебя пессимистичный взгляд на полупустой стакан, который на самом деле полуполон .
Re[3]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Судя по расказам авторов на CppCon, они сами струдом понимают как оно взлетит
A>ranges,
малюсенький синтаксический сахарок
A>contracts, concepts — вполне себе крупные фишки.
Тут мы опять подходим к вопросу про надрачивания, на сей раз на шаблоны. Ну это давно известный объект поклонения в C++-мире. Если незнаешь что рассказать на CppCon — изради новый шаблон в котором пользы чуть меньше чем нисколько и расскажи про него.
A>У тебя пессимистичный взгляд на полупустой стакан, который на самом деле полуполон .
Да если бы! Я говорю про реальные фишки нужные в повседневной продуктовой разработке. А не фишки ради фишек при помощи которых можно написать очередную крутую шаблонную библиотеку
Re[4]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, kaa.python, Вы писали:
A>>modules,
KP>Судя по расказам авторов на CppCon, они сами струдом понимают как оно взлетит
Да даже в статье написано, что модули еще предстоит принять в C++20, пока они еще не там.
Кроме того, старый код, который без модулей, на модули волшебным образом переписан не будет. Так что в лучшем случае нас будет ждать бесконечно долгий период сосуществования инклюдов с модулями.
A>>ranges,
KP>малюсенький синтаксический сахарок
Это как посмотреть. Даже если не потребуется использовать этот сахар в коде, то в рамках библиотеки Ranges определяется N-ое количество базовых концептов, которые затем можно переиспользовать.
A>>contracts, concepts — вполне себе крупные фишки.
KP>Тут мы опять подходим к вопросу про надрачивания, на сей раз на шаблоны. Ну это давно известный объект поклонения в C++-мире. Если незнаешь что рассказать на CppCon — изради новый шаблон в котором пользы чуть меньше чем нисколько и расскажи про него.
Разве стоит смешивать контракты и концепты? Это же разные вещи.
Появление контрактов в языке -- это очень интересный поворот событий.
Но в общем, все та же плавная эволюция, которая была и в C++14, и в C++17.
Re[2]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, kaa.python, Вы писали:
KP>Корутины не осилили, сеть не осилили. Да сколько можно!? Где concurrency TS? Где Transactional memory? Зато типичный плюсовый надроч на мелочевку и микрооптимизации
Вместо всего это ( ну кроме Transactional memory ) есть boost::coroutine2, boost::asio, hpx, ppl, tbb и т.д., так что жить можно, не фатально.
А вот modules, contracts, concepts заменить по понятным причинам нечем. Да и boost::ranges просто бледное подобие ranges v3.
Re: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, kaa.python, Вы писали:
KP>Да если бы! Я говорю про реальные фишки нужные в повседневной продуктовой разработке. А не фишки ради фишек при помощи которых можно написать очередную крутую шаблонную библиотеку
У каждого свой с++ Хотя я в resume-driven development не участвую, мне шаблонов надо постоянно в пользовательском коде и в либах моих.
Re[2]: Сан-Диего: С++20 и Modules, Networking, Coroutines, R
Здравствуйте, kaa.python, Вы писали:
АШ>>Статья Антона Полухина https://habr.com/company/yandex/blog/430406/ KP>Корутины не осилили, сеть не осилили. Да сколько можно!? Где concurrency TS? Где Transactional memory? Зато типичный плюсовый надроч на мелочевку и микрооптимизации
В чём-то согласен, а в чём-то нет.
Лично мой список пожеланий в порядке убывания важности:
1. Рефлексия (в смысле статической интроспекции) — самая необходимая вещь в C++, которая сделает ненужной огромный кусок Boost'а.
2. Спокойная работа с контейнерами (строками и т.п.) на этапе компиляции — необходимо для вменяемого метапрограммирования, в особенности для следующего пункта
3. Генерация кода на этапе компиляции (от банальной генерации по строке до метаклассов)
4. Аналог STL, но только для Ranges — будет инструмент эффективнее Linq
5. Концепты — для вменяемых сообщений об ошибках шаблонного кода
Из моего списка пункты 2, 4, 5 вроде как уже точно выйдут в C++20, пункт 1 возможно выйдет в C++23 (очень бесит что так тянут с самым важным, но хотя бы есть уверенность, что светлое будущее когда-нибудь настанет), пункт 3 пока обсуждают с разных сторон. Так что я в итоге не полностью доволен, но и не совсем разочарован.
По твоему списку претензий: Короутины и сеть давно есть в Boost'е, Concurrency TS — ну не самое лучшее пока предложение в данной области. Transactional memory на уровне языка — это да, было бы довольно инновационной возможностью.
Из принятого крупного и спорного: никогда не понимал желание ввести модули в язык, в котором имеется множестве библиотек, состоящих из одних заголовочных файлов. Такое впечатление, что люди мечтают о скорости сборки java/c#, забыв с каким языком имеют дело (с макросами, шаблонами и т.п.).
Так же интересно принятие контрактов — все остальные крупные изменения очень долго обсасывались сообществом перед принятием, а тут вот вдруг раз и с ходу приняли. Польза от этой возможности вполне понятна, хотя не сказал бы что когда-то испытывал острую необходимость в них.
Здравствуйте, Анатолий Широков, Вы писали: АШ>Статья Антона Полухина https://habr.com/company/yandex/blog/430406/
Окончательно убеждаюсь в том, что современный С++ двигают те, кто вчера писал BOOST. И, соответственно, двигают они его в таком направлении, чтобы потом переписать BOOST лаконичней и без оверхеда, и переместить его в namespace std.
Если серьезно, создается ощущение, что из языка делается идеальное средство для написания библиотек — одновременно гибких, быстрых и максимально обобщенных. Может, это и хорошо, но, конечно, и требования к квалификации писателей этих библиотек постоянно растет. То есть растет пропасть между квалификацией писателей библиотек и их пользователей. Еще во времена старого С++ прочитать исходники Boost/STL для того, чтобы понять как работает та или иная функция, было проблематично. Теперь это будет практически невозможно: "RTFM и никаких тебе GoToDefinition!". Зато, читаемые сообщения об ошибках (на каком языке?), максимально возможная оптимизация и, если повезет, вменяемая скорость сборки. С другой стороны вещей, которые облегчают ежедневное кодирование, после прорыва С++11 я как-то не замечаю. Прикладное программирование доведено до идеала и теперь нужно только "гладко всунуть все популярные библиотеки в стандарт"? Не знаю, не похоже.
Re[2]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Went, Вы писали:
W>>С другой стороны вещей, которые облегчают ежедневное кодирование, после прорыва С++11 я как-то не замечаю.
S>А библиотек для каких вещей не хватает?
А что из необходимого из повседневного использования покрывает стандартная либа? Записать/прочитать файл и больше практически ничего.
Re[2]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
И если бы оно ещё помогало им нормально писать библиотеки, а то... а то, вроде налабали а пользоваться либой без слёз невозможно:
— или калечный интерфейс: впечатление, что имплементили "писатели", которые точно этим пользоваться не будут
— или жесткая просадка по скорости (особенно доставляет, когда наколеночная имплементация разрывает МЕГАшаблонную либу по перформансу)
— или время компиляции улетает в космос (привет boost::spirit — как говорится, получи +20 минут на компиляцию, когда наколеночная версия справляется за 20 секунд)
boost по большей части уже и не нужен, только asio пока ещё требуется (но это ненадолго) — уже есть либы попроще, полегковеснее, с классным интерфейсом, с великолепным перформансом, но без бездумного метапрограммирования.
Re[2]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, kaa.python, Вы писали:
KP>Корутины не осилили, сеть не осилили. Да сколько можно!? Где concurrency TS? Где Transactional memory? Зато типичный плюсовый надроч на мелочевку и микрооптимизации
Корутины — единственное, чего не хватает.
Transactional Memory без железной поддержки не имеет смысла. Железная поддержка как-то не возникает всё и перспективы на несколько лет туманны.
Sapienti sat!
Re[3]: Сан-Диего: С++20 и Modules, Networking, Coroutines, R
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, kaa.python, Вы писали:
KP>>Корутины не осилили, сеть не осилили. Да сколько можно!? Где concurrency TS? Где Transactional memory? Зато типичный плюсовый надроч на мелочевку и микрооптимизации C>Корутины — единственное, чего не хватает.
Если говорить именно в таком ключе, то не хватает исключительно Карго. Всего остального вобщем-то хватает для фактически всего.
Здравствуйте, AeroSun, Вы писали:
W>>>С другой стороны вещей, которые облегчают ежедневное кодирование, после прорыва С++11 я как-то не замечаю.
S>>А библиотек для каких вещей не хватает?
AS>А что из необходимого из повседневного использования покрывает стандартная либа? Записать/прочитать файл и больше практически ничего.
Отвечать на вполне конкретный вопрос, заданный совсем другому форумчанину, своим риторическим вопросом -- это неконструктивно, по меньшей мере. Это во-первых.
Во-вторых, насколько нам известно, нет еще ни одного универсального языка программирования, стандартная библиотека которого позволяла бы закрывать все случаи. Всегда и везде используются сторонние библиотеки.
Так что если вам лично не хватает в C++ библиотек для решения каких-то ваших прикладных задач, то могли бы вы перечислить, чего лично вам не хватает?
Re[4]: Сан-Диего: С++20 и Modules, Networking, Coroutines, Ranges,
Здравствуйте, kaa.python, Вы писали:
C>>Корутины — единственное, чего не хватает. KP>Если говорить именно в том ключе, то не хватает исключительно Карго. Всего остального вобщем-то хватает для фактически всего.
Карго бесполезен без модулей. С модулями его можно будет заколхозить и без всякого стандарта.
.
