Now that we are close to knowing the final feature set of C++20, we can see will be C++’s largest release since C++11. “Major” features include at least the following:
modules
coroutines
concepts
contracts
<=> spaceship
“lots more constexpr”: broad use of normal C++ for direct compile-time programming, without resorting to template metaprogramming (see last trip report)
ranges
calendars and time zones
span
and lots more
Здравствуйте, Nuzhny, Вы писали:
BFE>>Забавно, что ssize() добавили.
N>Круто! Меня постоянно раздражает необходимость кастов из size_t при использовании omp parallel for
Покажи, пожалуйста, пример такого каста.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
N>>Круто! Меня постоянно раздражает необходимость кастов из size_t при использовании omp parallel for КД>Покажи, пожалуйста, пример такого каста.
// Update Kalman Filters stateconst int stop_i = static_cast<int>(assignment.size());
#pragma omp parallel for
for (int i = 0; i < stop_i; ++i)
{
...
}
То есть openmp не может использовать size_t в качестве переменной цикла.
P.S. Добавлю, что это из-за плохой поддержики OpenMP в Windows — только 2.0. В последующих стандартах дозволено и unsigned, но для кроссплатформенных приложений приходится подстраиваться под отстающих.
Здравствуйте, Nuzhny, Вы писали:
N>Вот например: N>
N>// Update Kalman Filters state
N>const int stop_i = static_cast<int>(assignment.size());
N>#pragma omp parallel for
N>for (int i = 0; i < stop_i; ++i)
N>{
N>...
N>}
N>
N>То есть openmp не может использовать size_t в качестве переменной цикла.
Хмм. Я совсем не в курсе параллельного исполнения циклов в современном коде, но знаю, что в стандарте есть такое:
template< class ExecutionPolicy, class ForwardIt, class UnaryFunction2 >
void for_each( ExecutionPolicy&& policy, ForwardIt first, ForwardIt last, UnaryFunction2 f );
Здравствуйте, B0FEE664, Вы писали:
N>>Вот например:
N>>То есть openmp не может использовать size_t в качестве переменной цикла.
BFE>Хмм. Я совсем не в курсе параллельного исполнения циклов в современном коде, но знаю, что в стандарте есть такое: ExecutionPolicy
Ну ты сравнил, конечно
ExecutionPolicy — since c++17. А OpenMP — since 1997! Не думаю, что как только приняли новый стандарт, так сразу весь код, написанный за 20 лет, магически под него переписали.
BFE>for_each
Ну и OpenMP предоставляет куда больше возможностей, чем доступно в стандартной библиотеки C++. Да, потихоньку и в ней появляется что-то полезное. И всякие там for_each для поэлементной обработки вполне себе имеют право на жизнь. Но если твоя функция не ложится в один из стандартных алгоритмов, то всё плохо.
BFE>и не нужно никаких переменных цикла.
Хорошо. Это ты сам сказал Вот выше есть пример довольно простого кода. Как его переписать на for_each без переменных цикла? И желательно чтобы он при этом остался ещё и читаемым.
А там всего-то итерируются по паре массивов. А если массивов 3? А если нужно обращаться к соседним элементам? А если нужно ещё и максимальный элемент найти и вернуть? В общем-то это всё не сложно, но с OpenMP это займёт на одну строчку больше чем эквивалентный однопоточный код. А попытка провернуть это через стандартную библиотеку выльется в ещё одну ad-hoc реализацию ranges
И опять же: OpenMP — это далеко не только parallel for.
Здравствуйте, The Passenger, Вы писали:
TP>asio так и нет?
Ага, как и рефлекшн перенесли на С++26. Короче, прикладные вещи будут не раньше С++50. Вангую, что к 2023 появится "более удобный с++". А "текущий с++" повторит путь кобола.
Кстати, про modules: встречал зарубежную статью, где тестилась реализация для стандарта.
И выходило, что модули в кандидатской реализации значительно увеличивают время сборки.
Есть какие-либо тесты с финальной реализацией? Что там со скоростью сборки?
Здравствуйте, LaptevVV, Вы писали:
AS>>Вангую, что к 2023 появится "более удобный с++". А "текущий с++" повторит путь кобола. LVV>А был "более удобный Кобол" ? Что-то я не помню...
Java?
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
AS>>>Вангую, что к 2023 появится "более удобный с++". А "текущий с++" повторит путь кобола. LVV>>А был "более удобный Кобол" ? Что-то я не помню... A>Java?
Не... Это совсем "из другой оперы".
Хочешь быть счастливым — будь им!
Без булдырабыз!!!