Comments 8
То что они "опустили" поддержку std::execution в ranges, вот так вот, это конечно просто уму непостижимо. Как если бы они сами не пользовались своим стандартом. Ведь это же очень логично, запустить read-only параллельную обработку данных. Это одна из причин, по которым я не пользуюсь ranges. Можно создать vector поверх read-only блоба и всё будет в целом ok. За исключением самой ситуации. А так было и со многим прочим, забыли то std::make_shared, то 1/sqrt(2*Pi), то ещё чего. Очень это всё странно.
это не "забыли".
В поддержке параллельности очень много подводных камней - никто не мешает вам использовать сейчас обычные алгоритмы для этого, если вам нравится.
Но вот откуда возьмётся тредпул для исполнения ваших задач вы явно не задумывались.
Будет ли он глобальным или треды каждый раз будут создаваться на месте. А может тредов вовсе не будет и всё исполнится однопоточно.
Над интерфейсом параллельности/асинхронности уже давно работают, вот когда это будет готово тогда будет ясно как должны выглядеть многопоточные алгоритмы в ranges, какой интерфейс нужен будет екзекуторам, какие дефолтные реализации должны быть и т.д.
Если добавить это сейчас, то в будущем придётся ломать код
Понимаю, что работают. КРАЙНЕ расслабленно. Зато — ритуальные принятия редчайших стат. распределений в Стандарт, лишь бы показать объём работы, вот мол, собираемся, трудимся! Создавать работу ради работы из-за бедности стандартной библиотеки и писать всё себе самописное — тоже так себе вариант.
Имхо, в плюсах акцент нужно держать не на STL, а на всяком движе связанном с модулями и с поддержкой пакетных менеджеров (очень желательно, продумать сразу поддержку версионирования). Подключение каждой новой библиотеки перестанет быть "приключением на 20 минут" и комьюнити получившее возможность легко "перебирать харчами" при выборе решения, методом естественного отбора само поднимет в топы использования более удобные библиотеки. Это снимет лишнюю нагрузку с Комитета и разработчиков компиляторов
Солидарен. Но в экосистемах класса Java или .NET у нас есть нормальные штуки из коробки, и возможность подключить что-то более кастомное (производительное, ...) со стороны. В C++ по-прежнему, считать JSON это какое-то усилие — сторонняя библиотека, которую наверняка ещё и допилил сам когда-то из-за того, что она всё равно не покрывает популярных случаев. Близкие чаяния — в этой статье https://habr.com/ru/post/455726/ и в библиотеках Poco.
Наличие абстракции тред-пула в стандарте напрашивается уже лет 15. Даже с приходом std::async это всё что-то невразумительное. Так, копнём внутрь его реализации в VC++ и обнаружим, что значение а-ля system_concurrency зашито в ней как число потоков вполне себе такого тред-пула, но полностью спрятанного внутри реализации. Это крайне странно. В итоге пиши-пропало, хочешь управлять степенью конкурентности/параллельности — "пожалуйте бриться", то есть пишем своё или ищем чужое, или даже boost не дай бог. Как будто авторы Стандарта сами НИКОГДА не писали тред-пулы и прочие самые-самые-самые обычные штуки для полноценной утилизации ресурса машины.
То есть, по итогу, реализации Стандарта, в котором тред-пула нет, все ваяют внутри тот или иной тред-пул! Но которым по Стандарту нельзя никак управлять. В Стандарте ведь его нет :) Ну это на мой взгляд просто никуда не годится.
Сорри, я имел в виду std::unique_ptr: https://herbsutter.com/gotw/_102/ . Вот Саттер пишет, что именно забыли в C++11. Я прямо вот вижу, как же пропускать бесплатный праздничный ужин в конце саммита, "давайте отложим это на 3 года".
That C++11 doesn’t include make_unique is partly an oversight, and it will almost certainly be added in the future. In the meantime, use the one provided below.
Это же просто настоящие хиппи! И то, "может быть добавлен" ? Мы будем слишком заняты добавлением численных решений уравнения Блека-Шоулза или чего-то такого, а это вот мы посмотрим потом. Я сам прекрасно понимаю, что в квант-финансах нужно распределение Вейбулла и т.д., но не ценой же расшатывания стройности языка. Ведь как говорил Бьярн, сила в общности, а тут вот так.
Алгоритмы диапазонов C++20 — сортировка, множества, обновления C++23 и прочее