Совершенный цикл for

    Сегодня необычный для меня формат статьи: я скорее задаю вопрос залу, нежели делюсь готовым рецептом. Впрочем, для инициирования дискуссии рецепт тоже предлагаю. Итак, сегодня мы поговорим о чувстве прекрасного.


    Я довольно давно пишу код, и так вышло, что практически всегда на C++. Даже и не могу прикинуть, сколько раз я написал подобную конструкцию:


    for (int i=0; i<size; i++) {
        [...]
    }

    Хотя почему не могу, очень даже могу:


    find . \( -name \*.h -o -name \*.cpp \) -exec grep -H "for (" {} \; | wc -l
    43641

    Наш текущий проект содержит 43 тысячи циклов. Проект пилю не я один, но команда маленькая и проект у меня не первый (и, надеюсь, не последний), так что в качестве грубой оценки пойдёт. А насколько такая запись цикла for хороша? Ведь на самом деле, важно даже не то количество раз, когда я цикл написал, а то количество раз, когда я цикл прочитал (см. отладка и code review). А тут речь очевидно идёт уже о миллионах.


    На КПДВ узел под названием «совершенная петля» (perfection loop).


    image


    Так каков он, совершенный цикл?


    А в чём проблема?


    Мы пишем много кода для математического моделирования; код довольно плотный, с огромным количеством целых чисел, которые являются индексами ячеек, функций и прочей лабуды. Чтобы был понятен масштаб проблемы, давайте я просто приведу крохотный кусочек кода из нашего проекта:


    for (int iter=0; iter<nb_iter; iter++) {          // some iterative computation
        for (int c=0; c<mesh.cells.nb(); c++)         // loop through all tetrahedra
            for (int lv0=0; lv0<4; lv0++)             // for every pair of
                for (int lv1 = lv0+1; lv1<4; lv1++)   // vertices in the tet
                    for (int d=0; d<3; d++) {         // do stuff for each of 3 dimensions
                        nlRowScaling(weight);
                        nlBegin(NL_ROW);
                        nlCoefficient(mesh.cells.vertex(c, lv0)*3 + d,  1);
                        nlCoefficient(mesh.cells.vertex(c, lv1)*3 + d, -1);
                        nlEnd(NL_ROW);
                    }
        [...]
    }

    У нас есть некая область, разбитая на тетраэдры, и мы на ней моделируем некий процесс. Для каждой итерации процесса мы проходимся по всем тетраэдрам сетки, затем по всем вершинам каждого тетраэдра, бла-бла-бла, и всё венчает цикл по всем трём измерениям нашего окружающего мира.


    Мы обязаны иметь дело с кучей вложенных циклов; вышеприведённые пять вложенных далеко не предел. Мы уже довольно давно (лет пятнадцать как) пришли к выводу, что стандартный for (int i=0; i<size; i++) — это очень громоздкая конструкция: те самые пять вложенных заголовков for превращаются в совершенно нечитаемую кашу, и даже подсветка синтаксиса не спасает.


    Когда мы читаем стандартный for(;;), мы должны на каждой строчке обратить внимание на три вещи: на инициализацию, на условие выхода и собственно на инкремент. Но ведь это совершеннейший оверкилл для тех случаев, когда нам нужно пройтись от 0 до size-1, а это подавляющее большинство всех циклов. Скажите, как часто вам приходится писать обратный цикл или итерацию с другими границами? Как мне кажется, один раз из десяти — это ещё щедрая оценка.


    До появления c++11 мы в итоге пришли к страшной вещи, а именно ввели в самый верхний заголовок вот такой дефайн:


    #define FOR(I,UPPERBND) for(int I = 0; I<int(UPPERBND); ++I)

    И тогда вышеприведённый кусок кода превращается из тыквы в кабачок:


    FOR(iter, nb_iter) {
        FOR(c, mesh.cells.nb())
            FOR(lv0, 4)
                for (int lv1 = lv0+1; lv1<4; lv1++)
                    FOR(d, 3) {
                        nlRowScaling(weight);
                        nlBegin(NL_ROW);
                        nlCoefficient(mesh.cells.vertex(c, lv0)*3 + d,  1);
                        nlCoefficient(mesh.cells.vertex(c, lv1)*3 + d, -1);
                        nlEnd(NL_ROW);
                    }
        [...]
    }

    Польза такой трансформации в том, что когда я встречаю for (;;), я знаю, что мне нужно насторожиться и внимательно смотреть на все три места (инициализацию, условие, инкремент). В то время как если я вижу FOR(,) то это совершенно стандартный пробег от 0 до n-1 без каких-либо тонкостей. Я совершенно не предлагаю пользоваться вышеприведённым дефайном, но точно знаю, что для нашей команды он сберёг много ресурсов мозга, поскольку мы кода гораздо больше читаем (см. отладка), нежели пишем (как, наверное, и все программисты).


    То есть, вопрос, которым я задаюсь, звучит так: "Как выглядит цикл, имеющий минимальную когнитивную нагрузку при чтении кода?"


    Жизнь после 11го года, или range for


    А как дела обстоят у соседей? Вы знаете, местами довольно недурно. Например, в лагере питонистов стандартный цикл выглядит следующим образом:


    for i in range(n):
        print(i)

    Что любопытно, до третьего питона range() создавал в памяти массив индексов, и проходился по нему. И со времён c++11 мы вполне можем делать точно так же!


    #include <iostream>
    int main() {
        int range[] = {0,1,2,3,4,5};
        for (int i : range) {
            std::cerr << i;
        }
    }

    Разумеется, явно создавать в памяти массив индексов это несерьёзно, и с третьей версии в питоне это тоже поняли. Но и в C++ мы можем сделать не хуже!


    Давайте посмотрим на следующую функцию range(int n):


    #include <iostream>
    
    constexpr auto range(int n) {
        struct iterator {
            int i;
            void operator++() { ++i; }
            bool operator!=(const iterator& rhs) const { return i != rhs.i; }
            const int &operator*() const { return i; }
        };
        struct wrapper {
            int n;
            auto begin() { return iterator{0}; }
            auto end()   { return iterator{n}; }
        };
        return wrapper{n};
    }
    
    int main() {
        for (int i: range(13)) {
            std::cerr << i;
        }
        return 0;
    }

    Пожалуйста, не начинайте int vs size_t, разговор не об этом. Если скомпилировать этот код при помощи gcc 10.2 с флагами компиляции -std=c++17 -Wall -Wextra -pedantic -O1, то мы получим следующий ассемблерный код (проверьте тут):


    [...]
    .L2:
            mov     esi, ebx
            mov     edi, OFFSET FLAT:_ZSt4cerr
            call    std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
            add     ebx, 1
            cmp     ebx, 13
            jne     .L2
    [...]

    То есть, компилятор начисто убрал все эти обёртки и оставил голый инкремент, ровно как если бы мы написали обычный for (int i=0; i<13; i++).


    Лично мне кажется, что for (int i: range(n)) справляется с подчёркиванием обычности цикла чуть хуже, нежели FOR(,), но тоже вполне достойно, и за это не нужно платить дополнительными тактами процессора.


    Продолжаем подглядывать в замочную скважину: enumerate


    Range for в c++11 нанёс большую пользу. Давайте скажем, что у меня есть массив трёхмерных точек, и мне нужно распечатать икс координаты каждой точки, это можно сделать следующим образом:


    #include <vector>
    #include <iostream>
    
    struct vec3 {  double x,y,z;  };
    
    int main() {
        std::vector<vec3> points = {{6,5,8},{1,2,3},{7,3,7}};
        for (vec3 &p: points) {
            std::cerr << p.x;
        }
        return 0;
    }

    for (vec3 &p: points) это прекрасная конструкция, никаких костылей, сразу из стандарта языка. Но что если у меня каждая точка из массива имеет цвет, вес или вкус? Это можно представить ещё одним массивом того же размера, что и массив точек. И тогда для доступа к атрибуту мне всё же понадобится индекс, который мы можем сгенерировать, например, вот таким образом:


        std::vector<vec3> points = {{6,5,8},{1,2,3},{7,3,7}};
        std::vector<double> weights = {4,6,9};
        int i = 0;
        for (vec3 &p: points) {
            std::cerr << p.x << weights[i++];
        }

    Для этого кода компилятор генерирует следующий ассемблер:


    asm
    .L2:
            movsd   xmm0, QWORD PTR [r13+0]
            mov     edi, OFFSET FLAT:_ZSt4cerr
            call    std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
            movsd   xmm0, QWORD PTR [rbp+0]
            mov     rdi, rax
            call    std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
            add     rbp, 8
            add     r13, 24
            cmp     r14, rbp
            jne     .L2

    В принципе, имеет право на жизнь, но гулять так гулять, давайте снимем с программиста заботу о создании параллельного индекса, ровно как сделали в питоне, благо стандарт c++17 имеет structural binding!


    Итак, можно сделать следующим образом:


    #include <vector>
    #include <iostream>
    #include "range.h"
    
    struct vec3 {
        double x,y,z;
    };
    
    int main() {
        std::vector<vec3> points = {{6,5,8},{1,2,3},{7,3,7}};
        std::vector<double> weights = {4,6,9};
    
        for (auto [i, p]: enumerate(points)) {
            std::cerr << p.x << weights[i];
        }
    
        return 0;
    }

    Функция enumerate() определена в следующем заголовочном файле:


    range.h
    #ifndef __RANGE_H__
    #define __RANGE_H__
    
    #include <tuple>
    #include <utility>
    #include <iterator>
    
    constexpr auto range(int n) {
        struct iterator {
            int i;
            void operator++() { ++i; }
            bool operator!=(const iterator& rhs) const { return i != rhs.i; }
            const int &operator*() const { return i; }
        };
        struct wrapper {
            int n;
            auto begin() { return iterator{0}; }
            auto end()   { return iterator{n}; }
        };
        return wrapper{n};
    }
    
    template <typename T> constexpr auto enumerate(T && iterable) {
        struct iterator {
            int i;
            typedef decltype(std::begin(std::declval<T>())) iterator_type;
            iterator_type iter;
            bool operator!=(const iterator& rhs) const { return iter != rhs.iter; }
            void operator++() { ++i; ++iter; }
            auto operator*() const { return std::tie(i, *iter); }
        };
        struct wrapper {
            T iterable;
            auto begin() { return iterator{0, std::begin(iterable)}; }
            auto end()   { return iterator{0, std::end  (iterable)}; }
        };
        return wrapper{std::forward<T>(iterable)};
    }
    
    #endif // __RANGE_H__

    При компиляции с флагами -std=c++17 -Wall -Wextra -pedantic -O2 мы получим следующий ассемблерный код (проверьте тут):


    ASM
    .L14:
            movsd   xmm0, QWORD PTR [rbx]
            mov     edi, OFFSET FLAT:_ZSt4cerr
            call    std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
            mov     rdi, rax
            mov     rax, QWORD PTR [rsp+32]
            movsd   xmm0, QWORD PTR [rax+rbp]
            call    std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
            add     rbx, 24
            add     rbp, 8
            cmp     r12, rbx
            jne     .L14

    И снова компилятор начисто убрал обёртку (правда, для этого пришлось поднять уровень оптимизации с -O1 на -O2).
    Кстати, в c++20 появился std::ranges, что ещё больше упрощает написание такой функции, но я пока не готов переходить на этот стандарт.


    Вопрос залу


    На ваш взгляд, каким должен быть совершенный цикл в 2020м году? Научите меня!


    Если вы ещё не задавались этим вопросом, то скопируйте к себе в пет-проект заголовочный файл range.h и попробуйте его поиспользовать хотя бы несколько дней.

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 170

      +18

      Во втором питоне был xrange (итератор). В целом, for in — это один из элементов хорошей эргономики языков, который появился относительно поздно.


      В Rust его эргономику подняли ещё выше. Не теряя общности протокола итерации, они сделали так:


      for x in 0..10 {
         ...
      }

      Более того, зацените с inclusive:


      for x in 0..=10 {
         ...
      }

      (досчитает до 10 включительно)


      А ещё много всего вкусного: https://doc.rust-lang.org/reference/expressions/range-expr.html

        +2
        Поэтому я и смотрю в сторону range for, но мне важно понять, как писать понятные циклы именно на цпп, т.к. вопрос перехода на что-то другое у нас не встанет ещё долго.
          +1
          Prelude> data Vec3 = Vec3 {x, y, z::Double} deriving Show
          Prelude> points = [Vec3 6 5 8, Vec3 1 2 3, Vec3 7 3 7]
          Prelude> mapM_ print  points
          

          Пример с выводом X в Haskell.
          ЗЫ: Только я не настоящий сварщик.
          ЗЫ: запускал в интерпретаторе ghci
          +10

          Это мы еще не вспоминали (0..10).map(function)

            +6
            Как мне кажется, в используемом автором примере интереснее всего использовать zip()
            Скрытый текст
            for (point, weight) in points.iter()
                                         .zip(weights)
            {
                println!("{}, {}", point.x, weight);
            }

            И для плюсов, невзирая на отсутствие в стандартной библиотеке он реализуется достаточно просто (сто лет кресты не использовал, так-что легкий копи-паст кода haqreu).
              +2
              А вот за zip спасибо! Забыл про него. Надо подумать, как бы поэлегантнее его сделать с переменным количеством аргументов (впрочем, сильно вряд ли кто-то захочет зипить больше трёх массивов, уж больно громоздкая запись будет).
                  0
                  Да, я уже посмотрел. В целом стараюсь стоять от буста подальше, хотя некоторые вещи оттуда можно перенять.
                  0

                  В хаскелле есть буквально zip/zip3/zip4, а больше обычно и правда не нужно.

                –1
                В целом, for in — это один из элементов хорошей эргономики языков, который появился относительно поздно.
                В Rust его эргономику подняли ещё выше. Не теряя общности протокола итерации, они сделали так:
                for x in 0..10

                Эргномика выше по сравнению с чем? Во многих языках такой синтаксис есть, с разными мелкими отличиями типа : вместо ... Да даже в питоне, который намного старше раста, выглядит похоже: for x in range(10), или for x in range(0, 10) если хотите нижнюю границу указывать.

                  0

                  По сравнению с for (int i = 0; i < ...; i++)

                    0

                    Так в первом комментарии было написано мол "вот есть обычный for-in, а в расте ещё эргономичнее его сделали". Вы же сравниваете не с for-in циклом.


                    Ну а сам for-in-range в питоне уже лет 20 существует, если не больше — думаю, даже это странно считать "относительно поздно" в плане развития языков программирования. Уверен, что в каких-то других языках такое и раньше было сделано.

                      +1

                      while/for в языках появился примерно на 20 лет раньше питона, насколько я понимаю. То есть я говорю, что конструкция for in появилась существенно позже, чем обычный for, то есть это относительно новое улучшение эргономики.

                    +3

                    Эргономика выше за счёт добавления range в синтаксис языка. 2..4 явно выразительнее, чем range(2,4). Букв меньше, скобок меньше.

                    +1

                    В Rust лучше использовать итераторы. Одновременно и читабельнее и быстрее. Не лишним будет упомянуть rayon (docs.rs). Многопоточные числодропилки в пару строчек можно делать:


                    use rayon::prelude::*;
                    
                    fn sum_of_squares(input: &[i32]) -> i32 {
                        input.par_iter()
                             .map(|i| i * i)
                             .sum()
                    }
                      +2

                      Очень "интересная" логика. По умолчанию, если выражаться математикой цикл [0,10). В расте об эргономике вообще не думают? Обычно сахар в виде ".." подразумевает полное включение от и до

                        +1

                        Думают, думают.


                        В большинстве случаев надо считать от нуля до N-1. Даже у автора поста именно этот случай описан.


                        Причина — если у вас есть N элементов, то у них номера от нуля до N-1.


                        Понятно, что математику непривычно. Но математику так же не привычно, что в компьютере нет ни натуральных, ни вещественных чисел. А ещё нельзя досчитать до бесконечности (в обоих направлениях).

                          +1

                          Во-первых, откуда "обычно", во-вторых, на практике полувключающие диапазоны удобнее

                          0

                          Посмотрел таки ради интереса по вашей ссылке — эта штука с двумя точками в расте очень ограниченная, ничего не поменялось с тех пор как я с ним игрался:


                          • Произвольный шаг в таком синтаксисе не поддерживается, для него нужно наворачивать (0..10).stepby(2).
                          • Можно использовать только со стандартными целыми числами, если я правильно понял: никаких вам bigint/float/datetime/… .
                            0
                            • Произвольный шаг в таком синтаксисе не поддерживается, для него нужно наворачивать (0..10).stepby(2).

                            С учётом того, что step_by работает не только на численных диапазонах, а на произвольных итераторах, не вижу, в чём проблема.


                            • Можно использовать только со стандартными целыми числами, если я правильно понял: никаких вам bigint/float/datetime/…

                            После стабилизации Step можно будет реализовать его для своих типов и использовать для нативных диапазонов. Если nightly не пугает, то можно и сейчас.

                              0
                              С учётом того, что step_by работает не только на численных диапазонах, а на произвольных итераторах, не вижу, в чём проблема.

                              Ну так соответствующая операция на итераторах в любом языке наверное есть, в котором итераторы используются. Даже в питоне — islice ровно это делает.
                              В общем, никак не понимаю чем итераторы именно в расте удобнее/эргономичнее, как тут выше писали — по-моему они совершенно обычные, возможности такие же как везде.


                              После стабилизации Step можно будет реализовать его для своих типов и использовать для нативных диапазонов.

                              О, это хорошо, рад за раст :)


                              Если nightly не пугает, то можно и сейчас.

                              Я растом по факту не пользуюсь, только игрался и посматриваю иногда на концептуальном уровне. Лично для меня он встал в категорию языков "придуманы и реализованы интересные/полезные идеи, но мне не подходит" — там же и например lisp, haskell. Мне для всяких вычислений, статистики и анализа данных (+ остальное по мелочи) главное — экосистема, которая в расте по сути отсутствует; ещё слишком многословно выглядит всё-таки, и слишком "низкоуровневый".

                          +1
                          Когда-то давно тоже об этом думал в том же ключе — макросы, коллекции индексов и так далее:
                          habr.com/ru/post/264803
                            +6
                            Почему вы не пошли с for дальше — в большинстве случаев вам индекс не нужен, вам нужно перечисление элементов. То есть следующий этап foreach.
                              0
                              Вы знаете, в большинстве случаев у меня даже основного массива элементов нет. Например, для конкретного дома номер 5 по Садовой улице у меня есть массив имён ответственных квартиросъёмщиков, есть булевский массив (того же размера) наличия в квартире счётчика холодной воды, целочисленный массив (опять же того же размера) задолженности по оплате лифта и тому подобное, то есть, куча атрибутов для каждой квартиры. А вот непосредственно массива квартир у меня нет, они неявно присутствуют в индексе массивов. Поэтому `std::for_each` для меня тупиковый путь. Мне нужна возможность получить доступ ко всем данным для каждой взятой квартиры.
                                +2

                                Звучит как zip() + filter() или даже filter_map(). С хорошей базой итераторов можно много делов наворотить.

                                  +6

                                  Вам скорее нужна правильная абстракция, позволяющая работать со структурой массивов, как с массивом структур.

                                    0
                                    Да, возможно. Есть идеи помимо зипа?
                                      0

                                      Специальный контейнер, возвращающий прокси, которые берут данные из массивов по заданному смещению.

                                        0
                                        Учитывая, что у меня массивов каждый раз разное количество и каждый разного типа, я пока вижу только зип, который возвращает std::tuple для данного смещения…
                                          +1

                                          Ну да, в этом случае только zip.

                                            0

                                            Лучше не tuple, а namedtuple (есть такое в C++?), или struct — чтобы обращаться нормально по имени, типа a[i, j].cost. Не скажу за C++, но я иногда пользуюсь таким виртуальным представлением struct-of-arrays в виде array-of-structs — удобно, когда работающая с ним функция особо не заморачивается, какой из этих двух вариантов ей передали.

                                              0

                                              tuple можно легко разобрать на запчасти при помощи structural binding, так что имена будут красивыми.

                                                0

                                                Только если типы в кортеже одинаковые, то их легко перепутать

                                                  0

                                                  Ну, если запись вида


                                                  std::vector<int>  width(n);
                                                  std::vector<int> height(n);
                                                  [...]
                                                  for (auto [w,h] : zip(width, height)) {
                                                       [...]
                                                  }

                                                  то перепутать сложно. А вот если объявление кортежа дальше, то да, можно перепутать. Но тут мы говорим именно о таком локальном объявлении.

                                                  0

                                                  Я имел в виду какой-то такой сценарий, в котором обычно пользуюсь SoA-as-AoS. Есть функция, которая обрабатывает массив структур:


                                                  f(A) = [a.field_1 + a.field_2 for a in A]

                                                  Ещё есть функция, которая работает с обычными числовыми массивами:


                                                  g(A, B) = A * B

                                                  И нужно несколько раз по очереди их применять к данным одного и того же массива. Тогда пишу примерно так:


                                                  field_1 = ... # массив чисел
                                                  field_2 = ... # массив чисел
                                                  A_s = StructArray(field_1=field_1, field_2=field_2)
                                                  
                                                  for iter in 1:niters
                                                      xxx = f(A_s)
                                                      yyy = g(A_s.field_1, A_s.field_2)
                                                  end

                                                  Тут важно, чтобы элементы A_s представлялись как структуры с правильными названиями полей, иначе f(A_s) не сработает.


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

                                    0
                                    del
                                      +7
                                      Лучше всего со вложенными циклами дела обстоят у scala, в одной конструкции for делаются все уровни:

                                      for (a <- 0 to 4; b <- 1 to 5; c <- 'a' to 'c') {
                                        println(s"$a, $b, $c")
                                      }


                                      output:

                                      0, 1, a
                                      0, 1, b
                                      0, 1, c
                                      0, 2, a
                                      0, 2, b
                                      0, 2, c
                                        +14

                                        Я скалу не знаю, но глядя на этот синтаксис у меня есть сразу же куча интерпретаций:


                                        1. Одновременная итерация по трём итерейбл (типа for x in zip()) до момента пока все итерируются.
                                        2. Одновременная итерация по трём итерейбл (типа for x in zip()) до момента пока хотя бы одна итерируется.
                                        3. Три вложенных цикла (слева направо)
                                        4. Три вложенных цикла (справа налево).

                                        Так что не очень выразительно.

                                          –3
                                          Главное ни в коем случае не смотрите на output под кодом, а то неинтересно когда вместо четырех интерпретаций остается только одна.
                                            +9
                                            Вы знаете, но если нужно смотреть на вывод для того, чтобы понять, что делает кусок кода, это тревожный звоночек. Впрочем, scala и rust это интересно, но меня интересует как улучшить читаемость кода именно на C++ в рамках уже существующих стандартов. Хотя, конечно, примеры из параллельных вселенных интересно изучить, вдруг что можно перенять…
                                              +5
                                              Вы просто написали что подглядываете за соседями, я вас познакомил с еще одним соседом. Синтаксис может казаться непривычным, с первого взгляда код скалы и вправду понять непросто, но есть такое расхожее мнение — кто начинает писать на скале, на других языках писать больше не хотят. Так что это просто пример, согласитесь что
                                              for (a <- 0 to 3; b <- 1 to 4; c <- 2 to 5)
                                              выглядит куда компактней, чем
                                              for (int a = 0; a < 4; a++) {
                                                for (int b = 1; a < 5; b++) {  
                                                  for (int с = 2; a < 6; c++) {  


                                              По крайней мере это выглядит любопытно
                                                +1
                                                Может оно и выглядит любопытно, но мне кажется всё же нечитаемым. По крайней мере, мне нужно конкретно щуриться и выделять текст блоками, чтобы понять, что происходит в этом цикле. Кроме того, не забывайте, что в реальном коде не будет простых границ как в вашем примере, это будут другие переменные/константы/вызовы функций, что читаемости не прибавит никак.

                                                В сях тоже можно при желании вложенные циклы сделать в рамках одной конструкции for(;;). Но это как с тем троллейбусом: зачем?
                                                  +6
                                                  На самом деле там 3 конструкции, for не более чем сахар и написать можно еще так:

                                                  for {
                                                    a <- 0 to 3
                                                    b <- 1 to 4
                                                    c <- 2 to 5
                                                  } {...}
                                                  
                                                    0
                                                    О, так читается гораздо лучше. Но я хочу идти ещё дальше, я хочу, чтобы самый частый цикл не имел даже упоминания о нижней границе. Только имя переменной и верхняя граница. Именно поэтому в моей имплементации `range(int n)` имеет только один аргумент, а не три, как в питоне. Если вдруг мне понадобится пробежать не 0..n-1, у меня будет цикл другого вида, без слова `range`, и это привлечёт моё внимание.
                                                      +5

                                                      Может тогда к такому нужно стремится


                                                      for (auto [a, b, c]: range(4, 5, 6)) {
                                                          std::cerr << a << b << c;
                                                      }
                                                        +1

                                                        Сделал на JS, получилось в 30 раз медленнее вложенных циклов


                                                        for(const [x, y, z] of matrix(100, 100, 100)) {
                                                            console.log(x, y, z)
                                                        }

                                                        Исходный код
                                                        function* matrix() {
                                                          const len = arguments.length,
                                                                values = Array(len).fill(0)
                                                        
                                                          for(let pos = len - 1;;) {
                                                            while(values[pos] < arguments[pos]) {
                                                              yield values.slice()
                                                              values[pos]++
                                                            }
                                                            while(pos-- > 0 && values[pos] + 1 === arguments[pos]);
                                                            if(pos < 0) break
                                                            values[pos]++
                                                            while(++pos < len) values[pos] = 0
                                                            yield values.slice()
                                                          }
                                                        }
                                                        
                                                        const a = 100
                                                        
                                                        let time1 = -performance.now()
                                                        let res1 = 0
                                                        // for(let i = 0; i < 10000; i++)
                                                          for(const [x, y, z] of matrix(a, a, a)) {
                                                            res1 += x + y + z
                                                          }
                                                        time1 += performance.now()
                                                        
                                                        let time2 = -performance.now()
                                                        let res2 = 0
                                                        // for(let i = 0; i < 10000; i++)
                                                          for(let x = 0; x < a; x++) {
                                                            for(let y = 0; y < a; y++) {
                                                              for(let z = 0; z < a; z++) {
                                                                res2 += x + y + z
                                                              } 
                                                            } 
                                                          }
                                                        time2 += performance.now()
                                                        
                                                        console.log(res1 === res2, res1) // true 148500000
                                                        console.log('Matrix:', time1, 'ms') // "Matrix:" 925.7049999978335 "ms"
                                                        console.log('Loop:', time2, 'ms') // "Loop:" 30.43500000057975 "ms"
                                                        console.log(time1 / time2) // 30.32500790616872
                                                          +4

                                                          Ну, это же JS, тут не бывает zero-cost абстракций.

                                                            0
                                                            А где такое можно провернуть с zero-cost? Не представляю, как здесь constexpr использовать.
                                                      0
                                                      Но я хочу идти ещё дальше, я хочу, чтобы самый частый цикл не имел даже упоминания о нижней границе.

                                                      Можно создать implicit класс для чисел или любого другого типа, и потом писать что-то вроде for (i<-5.times){...} или 5 times { .... }.
                                                      Но более привычно выглядят варианты for(i<-0 until 5){...} и for(i<- array.indices){ ... }.

                                                      0
                                                      а как на скале написать с++ аналог:

                                                      for(int = i=0,j=0; i<5;i++,j++) — цикл один, а переменных несколько?
                                                      как не спутать с тем что в примере с вложенными.
                                                        +1

                                                        По-хорошему такой цикл через zip делается, хоть на скале хоть на чём: for (i, j) in zip(0:4, 0:4) с поправками на детали синтаксиса разных языков.

                                                          0
                                                          Как-то так (можно и в одну строчку свернуть):
                                                          for {
                                                            j =  0
                                                            i <- 0 to 5
                                                            j += 1
                                                          }
                                                          


                                                          Но, с большой вероятностью, за такой код в scala сообществе закидают тапками )
                                                        +6
                                                        оно вам видится нечитаемым потому что вы не знакомы с этой парадигмой. если привыкнете ней — этот код будет намного более читаемым, и щуриться не надо.К тому же короче, что тоже помогает чтению при прочих равных.
                                                        0
                                                        b < — 1 to 4;

                                                        С одной стороны, визуально кажется что там отрицательное значение -1
                                                        for (int b = 1; a < 5; b++) {

                                                        С другой стороны, возможен баг за счет копипасты
                                                    0

                                                    for в скала это обычная do-нотация, о чем можно легко догадаться по <-, следовательно вспоминаем как реализован стандартный аппликатив для списков — каждый с каждым.

                                                    0

                                                    Для более полной демонстрации циклов scala я бы привёл пример посложнее:


                                                    for(i<-0 until 10;
                                                        k=h(i);
                                                        j<-1 to 5 if f(j,k)>5; 
                                                        _ = println(s"$i $j $k"); 
                                                        (v,5)<-someIterable){
                                                       ...
                                                    }
                                                    

                                                    И это ещё без yield (который в scala довольно убогий по использованию и производительности).

                                                    +8

                                                    / sarcasm
                                                    В 2020 должна быть функциональщина с хвостовой рекурсией вместо цикла
                                                    /


                                                    Ну а если серьезно — зависит от требований и контекста. Если не нужна оптимальная производительность, то можно действительно использовать функциональщину или что-то типа LINQ из С# аля method chaining (не знаю, завезли ли такой синтаксис в плюсы уже наконец-то). Если производительность таки важна, можно попробовать вынести циклы выше 3-го уровня вложенности в отдельную функцию, в надежде что умный компилятор все заинлайнит. Желательно вынести так чтоб это ещё и имело какой-то «физический смысл», тобишь было очевиден новичку в проекте.


                                                    Ну и да, я лично целиком поддерживаю ваше желание убрать «лишние буквы» — чем меньше букв тем проще читать код (обычно, бывают исключения).

                                                      +3
                                                      Мне крайне важна производительность, мы пишем конкурентноспособные числодробилки, так что любая абстракция пойдёт до тех пор, пока компилятор её способен воплотить при нулевой стоимости по сравнению с обычным си. Разумеется, мы выносим внутренности в отдельные функции, но это не всегда возможно.
                                                        0

                                                        Ложная дилемма. В расте итераторы быстрее циклов. Потому что итераторы автоматически выкидывают все проверки индексов, например.


                                                        То что LINQ в шарпе реализован через одно место не означает, что нельзя делать быстрые и эффективные итераторы.

                                                          0

                                                          Я в общем-то имел в виду не то что LINQ медленный, а то, что переход на функциональщину (генераторы, иммутабельность, алгебраические типы, и т.п.) может при правильном применении упростить код, но (обычно) негативно сказывается на производительности, т.к. у оптимизатора появляется сильно больше работы. Ну и синтаксис С++ не позволит эти вещи использовать «удобно» (в том же расте тут все сильно лучше). Опять же, оптимизатор, возможно, сможет перелопатить функциональщину, но это нужно проверять «отдельно» — за читабельность и удобство отладки приходится платить.


                                                          Ну а что касается LINQ в шарпе — с ним не все так плохо — за ~20% замедления код получается намного более читабельным. К тому же, LINQ в шарпе реализует генераторы, а не итераторы/ренжи — по сути, это монада List из хаскелл — многие операции LINQ позволяют работать с “бесконечными” последовательностями. Исключение составляют операции требующие полной материализации (например, OrderBy). Соответственно, LINQ реализован поверх ко-процедур, а не поверх итераторов, что и даёт накладные расходы (точнее, усложняет работу оптимизатора).

                                                            0

                                                            Не обязательно там сопрограммы. Простые операторы там как раз итераторами сделаны.

                                                              0

                                                              Ну сопрограммы в что-то такое и компилируются :) Именно это я и имею в виду под сложностями для оптимизатора — ему теперь надо понимать что это временный объект чтоб полностью убрать его из GC (не уверен что оптимизатор вообще такое умеет)

                                                              0
                                                              Я в общем-то имел в виду не то что LINQ медленный, а то, что переход на функциональщину (генераторы, иммутабельность, алгебраические типы, и т.п.) может при правильном применении упростить код, но (обычно) негативно сказывается на производительности, т.к. у оптимизатора появляется сильно больше работы.

                                                              Это как раз наоборот. При использовании ФП примитивов у оптимизиатора больше возможностей, а не меньше. Классический пример, в обычном цикле for компилятор обязан проверять выход за границы массива. При этом при использовании foreach на итераторе он знает, что выхода за границы не будет и можно их выкинуть. С декларативным описанием программист сообщает больше информации о том, что он хочет получить в итоге, а не как, поэтому компилятору дается больше свободы в реорганизации кода чтобы получить нужый результат.


                                                              Ну а что касается LINQ в шарпе — с ним не все так плохо — за ~20% замедления код получается намного более читабельным.

                                                              Только не 20% — а на порядок


                                                              img

                                                          +2
                                                          На КПДВ узел под названием «совершенная петля» (perfection loop).

                                                          прошу ногами сильно не бить, но «совершенная петля» это «perfect loop», а «perfection loop» это «петля совершенства».
                                                            +2
                                                            А чего ногами-то бить. Я привёл названия (причём со ссылкой) на двух языках, переводил не я. И я не уверен, что в русский язык название пришло из английского, а не, скажем, голландского…
                                                              +1

                                                              "perfection" в данном случае неоднозначно — можно перевести как "петля совершенствования", c учётом контекста статьи очень даже интересная игра слов получается.

                                                              0
                                                              Мне одному кажется, что если значения можно разместить в массивах, то самое удобное оформление вложенных циклов реализовано в фортране? Например:

                                                              real a(10,10,10), b(10,10,10), c(5)
                                                              integer i,j,k
                                                              forall (i=1:10, j=2:10:2, k=6:8, b(i,j,k) /= 0)
                                                              a(i,j,k) = 3 * i / b(i,j,k) + c(j/2)
                                                              end forall
                                                                0
                                                                Я не уверен, что это самое удобное. Кроме того, мне нужно понять, как жить дальше именно c C++ :)
                                                                  –4
                                                                  по старинке жить надо. какой смысл в новомодных извращениях если они не дают выигрыша в скорости судя по асму. попытки сокращения, внесения всяких символов и повышения смысловой нагрузки в конструкциях языка несет только одно — ухудшение читаемости и понимаемости кода обычным человеком. тупо повышается порог вхождения в профессию и стоимость услуг. изначально смысл появления языков высокого уровня был в снижении этого порога.
                                                                    +1
                                                                    Выиграть в скорости у обычного for(;;) вряд ли удастся. А с утверждением, что любая попытка ввести стиль программирования приводит к ухудшению читаемости, я не согласен категорически. Вы примеры из статьи смотрели?
                                                                      –1
                                                                      естественно я всю статью прочитал. я про стили ничего не говорил. у меня стиль вообще своеобразный тк я все время был одиночкой и форматирую свой текст для своего удобства. {}=>[]<=() когда этого становиться много в языке это зло. но я начинал с паскаля на см-4… и предпочитаю легко читать и писать код, а не разгадывать символьные ребусы и запоминать вычурные конструкции языка.
                                                                        +1
                                                                        Вы о каких вычурных конструкциях-то? У меня нет предложения реорганизовать рабкрин (простите, стандарт c++). У меня есть конкретный вопрос о том, как писать на современном c++ таким образом, чтобы это экономило усилия разработчика в рамках одной команды. То есть, о стиле программирования в рамках одного проекта. У нас текучка небольшая, и мне несложно объяснить стиль каждому новому человеку.
                                                                          –1
                                                                          мне непонятно зачем читать эти циклы. почему они не в функциях с нормальным говорящим названием.
                                                                            +1
                                                                            Если мне нужно пробежать все ячейки кубической сетки, то у меня по-любому будет три вложенных цикла, будь они разнесены по функциям или нет.
                                                                              –1
                                                                              ну и зачем их читать. оформили в функцию с параметрами и читайте эти параметры в одной строчке. по мне так это вопрос уровня создания меню. пишется и вызывается MakeMenu(). А уже MakeMenu совершенно тупая функция в которой куча InsertItem(). ну или я чего-то не понимаю.
                                                                                +2
                                                                                Оформление для грядущих поколений это хорошо. Но для начала код нужно написать и отладить. И я вас уверяю, во время отладки этот код читается много-много-много раз.
                                                                                0

                                                                                Не обязательно три вложенных цикла — можно по массиву этих ячеек в линейном порядке проходить. Если проходимая структура более сложная, чем многомерный массив, то казалось бы можно один раз реализовать функцию обхода по ней с индексом, а потом эту функцию только использовать как аргумент в for-in. Или у вас такое решение по какой-то причине не проходит?

                                                                                  0
                                                                                  Давайте забудем про три вложенных, скажем, мне нужно два вложенных для обработки изображения. Да, я могу пройтись одним линейным циклом по всем пикселям изображения, но если мне нужно каждый пиксель усреднить с его четырьмя соседями, то мне нужны индексы (i,j) для каждого пикселя. Да, я смогу их получить целочисленным делением и взятием по модулю из линейного индекса, но насколько это оправдано?
                                                                                    0

                                                                                    По-моему такой сценарий абсолютно типичный и не требует написания вложенных циклов по размерностям каждый раз. Один раз реализуете функцию обхода-по-индексам если её нет, и потом эту функцию используете. Я бы примерно так сделал (пример на джулии, т.к. в современном c++ почти не ориентируюсь; но код не завязан фундаментально на язык):


                                                                                    A = ... # наш массив
                                                                                    offsets = CartesianIndex.([(-1, 0), (1, 0), (0, -1), (0, 1)])
                                                                                    for I in CartesianIndices(A)
                                                                                        cnt = 1
                                                                                        for off in offsets
                                                                                            if checkbounds(Bool, A, I + off)  # для примера игнорируем "соседей" вне границ массива
                                                                                                cnt += 1
                                                                                                A[I] += A[I + off]
                                                                                            end
                                                                                        end
                                                                                        A[I] /= cnt
                                                                                    end

                                                                                    При этом, как видно из кода, очень легко обобщить на произвольное понимание "соседей" клетки, на многомерные массивы, и т.п. — явно удобнее, чем вложенный цикл на каждую размерность массива, и захардкоженные координаты соседей.

                                                                      –1
                                                                      как жить дальше именно c C++

                                                                      Зачем вам этот дедушка с его неизлечимыми проблемами?

                                                                        +1
                                                                        Простите, а какие варианты? Раст?
                                                                          0
                                                                          Дмитрий $mol наверное предложит
                                                                            0

                                                                            $mol он для веба предлагает, а тут он предложит D (это язык такой, не смайлик)

                                                                          0

                                                                          Хороший вариант, между прочим.

                                                                      +3

                                                                      Запись вложенных циклов одной строкой — согласен, удобная фича, тоже часто пользуюсь. Но почти больно :) смотреть на повторение i,j,k трижды в вашем блоке кода: иногда попадался на опечатках в таких случаях, особенно если индексы массива из переменных цикла получаются сложнее (типа a[i + 2, j, k * 3]), или идут в другом порядке, или надо будет потом подправить это место. Поэтому теперь стараюсь писать так (пример на julia), т.е. не повторяя много раз получение индекса массива:


                                                                      for i in 1:10, j in 2:2:10, k in 6:8
                                                                          I = CartesianIndex(i, j, k) 
                                                                          if b[I] == 0 continue end
                                                                          a[I] = 3 * i / b[I] + c[j ÷ 2]
                                                                      end
                                                                        –1
                                                                        Мне одному кажется, что если значения можно разместить в массивах, то самое удобное оформление вложенных циклов реализовано в фортране? Например:

                                                                        real a(10,10,10), b(10,10,10), c(5)
                                                                        integer i,j,k
                                                                        forall (i=1:10, j=2:10:2, k=6:8, b(i,j,k) /= 0)
                                                                        a(i,j,k) = 3 * i / b(i,j,k) + c(j/2)
                                                                        end forall

                                                                        Но ведь от этого отказываются?
                                                                        The FORALL construct is an obsolescent language feature in Fortran 2018.

                                                                        Deleted and Obsolescent Language Features

                                                                        Без forall и where, просто do concurrent.
                                                                        stackoverflow.com/questions/4122099/do-fortran-95-constructs-such-as-where-forall-and-spread-generally-result-in-fa/4141572#4141572
                                                                        stackoverflow.com/questions/8602596/fortran-forall-restrictions

                                                                        Сложные расчёты всё равно не для gcc, а ICC/IFC, Nvidia/PGI, IBM, Cray и прочие.
                                                                        Там уже есть свои образцы использования for/forall/foreach…
                                                                        parallel-for.sourceforge.net/index.html
                                                                        parallel-for.sourceforge.net/parallelfor.html

                                                                        Пример: берёте железо Nvidia, вам дают инструменты для его правильного использования.
                                                                        Можно при желании доопределить свои конструкции — в рамках выбранной связки «железо + ПО». Но потом придётся разбираться что там компилятор наделал — насколько хорошо распараллелил.

                                                                        Какой смысл делать свой местечковый стандарт? NIH?
                                                                          0
                                                                          Сложные расчёты всё равно не для gcc, а ICC/IFC, Nvidia/PGI, IBM, Cray и прочие.

                                                                          Это вы сильно загнули. Опыт HPC с gcc имеете?

                                                                          Мы не делаем местечкового стандарта, а думаем о стиле оформления проекта, а это в любой серьёзной конторе есть.
                                                                            0
                                                                            Тоже не увидел смысла в этом
                                                                          +1
                                                                          Я не уверен, что это самое удобное. Кроме того, мне нужно понять, как жить дальше именно c C++ :)

                                                                          В статье был намек на соседей… это просто пример. Причем из языка, который достаточно широко используется для моделирования, и по эффективности мало кому уступает. Что позволяет писать вычислительную часть на фортране и цеплять эти функции к проектам на других языках. Но у С++ эффективность сравнима с фортраном (если сравнивать хорошие компиляторы), поэтому переписывать уже имеющийся проект смысла нет, разумеется. Особенно с учетом отсутствия разработчиков, владеющих этим хорошим, но очень уж узконишевым языком…
                                                                          А вопрос удобства всегда имеет субъективный оттенок, естественно. Но массивы и их сечения в современном фортране действительно очень мощные. А элементы ООП, которые в него тоже недавно (лет 20 назад) добавили, позволяют делать большие проекты с хорошо читаемым кодом. Если, конечно, там нет унаследованных из древности простыней на фортране-66 с вычисляемыми GOTO и прочими подобными ужасами ;-). Которые хотя и признаны устаревшими (и категорически не рекомендуются к использованию), но до сих пор поддерживаются компиляторами «для совместимости»…
                                                                            0
                                                                            Фортран хорошая штука, и даже для наших целей (матмоделирование), казалось бы, должен подходить. Но при ближайшем рассмотрении оказывается, что (современный) C++ гораздо удобнее (нам) даже несмотря на то, что мы отказались от сложных динамических структур данных и всё упаковываем в большие массивы.
                                                                              +2
                                                                              C++ гораздо удобнее (нам)

                                                                              Если можно, было бы интересно узнать — по каким критериям удобнее?
                                                                                0
                                                                                Вы знаете, если отвечать предельно честно, то самый главный критерий это то, что практически никто не знает современного фортрана (например, стандарт 2018го года). Ну а вокруг этого можно навернуть всяких рассуждений о гибкости C++ и тому подобного. Лично мне удобно, что абсолютно один и тот же код может исполняться как на CPU, так и на GPU при помощи препроцессора (си/куда).

                                                                                Как я и говорил, мы отказались от сложных структур данных, и все реальные данные упакованы в std::vector<>. Но поверх этих векторов у нас есть zero cost abstractions, которые облегчают разработку. Насколько я знаю (внимание, я не специалист), всякие shared pointer возможны в фортране, но это нужно конкретно над ними работать. В цпп они доступны из коробки. Так что гибкость я бы не сбрасывал со счетов.

                                                                                Мне очень интересно, что вы думаете об областях примения фортрана и цпп.
                                                                                  +1
                                                                                  К сожалению, я здесь могу только спрашивать, а не отвечать, так как являюсь типичным динозавром, давно закостеневшим в развитии, и не вымершим вовремя только в силу какого-то недоразумения. Поэтому мой взгляд на этот вопрос совершенно односторонний…
                                                                                  Если подробно, то мы уже 30 лет пилим очень узконишевую программу для научных исследований, причем основная часть сделана на фортране, а интерфейс — на плюсах. Я сам программирую только на фортране, за плюсы отвечает другой человек (и его код я понимаю ровно настолько, чтобы вносить туда совершенно косметические изменения вроде исправления опечаток в комментах ;-)).
                                                                                  Но что касается именно перемалывания чисел, то у фортрана это получается очень даже неплохо. Второй важный нюанс — весь фортрановский код, написанный нами лет 20 назад, до сих пор не только работает, но и при необходимости модифицируется с расширением функционала, и это не требует сверхусилий. Хотя наверно это зависит не только от языка… но для данного конкретного применения фортран вполне адекватен.
                                                                                    0
                                                                                    Наверное, я не умею готовить фортран, но лично у меня гибкая и расширяемая база кода получается именно на цпп. Перегрузка операторов, шаблоны и прочая фигня мне сильно помогает. Компиляторы C++ наконец-то догнали фортрановские, и теперь аргумент скорости уже не работает. Наверное, всё же очень сильно зависит от того, что нужно писать. Я наш цпп код спокойно запускаю в браузере (emscripten), и мне это часто нужно. У фортрана с этим напряжёнка. Так что, чистые конечные элементы на фортране хорошо, но вокруг этого обвязки на цпп вряд ли удастся избежать. В итоге мы и FEM делаем на чистом C++.

                                                                                    Но повторюсь ещё раз: очень мало людей знакомы с современным фортраном, можно даже сказать что это молодой язык, как бы парадоксально это ни звучало.
                                                                                      0
                                                                                      Перегрузка операторов, шаблоны и прочая фигня мне сильно помогает.
                                                                                      В принципе, из всех подобных фишек в Фортране отсутствуют только шаблоны. Вместо них есть лишь параметризация типов — это частный случай шаблонов.
                                                                                0
                                                                                даже несмотря на то, что мы отказались от сложных динамических структур данных и всё упаковываем в большие массивы.
                                                                                если вам часто приходится итерироваться по многомерным массивам, лучше напишите нормальный многомерный массив, по которому можно итерироваться через range-based for, и используйте его:
                                                                                for (auto& row : arr) {
                                                                                    for (auto& x : row) {
                                                                                        ...
                                                                                    }
                                                                                }
                                                                                  0
                                                                                  Нет, у нас все массивы одномерные. Ну, всякие разреженные матрицы не считаем за двумерный массив :)
                                                                                    0
                                                                                    Можно использовать прокси-объекты, которые будут ссылаться на строки в одномерном массиве. Правда есть накладные расходы на созданеи такого объекта
                                                                                +3

                                                                                Отвечу как человек, которому приходится много кодить на Фортране. (При этом не могу сказать, что являюсь большим фанатом этого языка. Почему — дальше по тексту). У Фортрана есть много преимуществ для численных расчётов, плюс язык вышел из комы, в которой он находился в 90-х, и на данный момент существует более-менее постоянная комиссия, которая занимается развитием стандарта. Но у этого стандарта есть, как минимум, две проблемы: 1). обратная совместимость требует тащить с современный язык всякие архаизмы; 2). другая проблема, характерная и для многих других соверменных языков, — нет какой-то чёткой цели развития. В итоге, многие новшества добавляются ad hoc, приводят к усложнению, которое не всегда окупается потенциальными преимуществами. К примеру, начавшееся со стандарта 2003 движение в сторону ООП сильно притормозилось, а использование этих черт языка в нынешнем их виде зачастую приводит к сильному проседанию производительности. И никаких улучшений в виде zero-cost abstractions в следующем стандарте 202х не планируется.


                                                                                Поэтому ситуация на данный момент такова, что если у вас уже есть значительная кодовая база на Фортране (не обязательно legacy, может быть стандарт 90 или 2003), то переходить на C++ или что-то другое смысла нет (тем более, что у C++ своих подобных проблем со стандартом вагон и маленькая тележка), т.к. на современном Фортране можно относительно комфортно писать высокопроизводительный код, если смриться с некоторыми корявостями. Если же у вас проект уже написан на C++, то я бы точно не советовал переходить на Фортран. На мой взгляд, будущее обоих этих классических языков довольно туманно, поэтому это будет смена шила на мыло. Если же начинать проект с нуля, то стоит уже смотреть в сторону чего-нибудь типа Julia. К сожалению, этот язык ещё не выбрался из стадии альфа.


                                                                                (Речь идёт о численных расчётах, поэтому rust, go и далее по списку — не предлагать.)

                                                                                  0
                                                                                  На мой взгляд, будущее обоих этих классических языков довольно туманно

                                                                                  Это точно. Я пишу на C/C++ уже четверть века, и чем дальше, тем больше он меня пугает. Но внятной замены пока не вижу.
                                                                                    0

                                                                                    Чем D не внятен?

                                                                                      0
                                                                                      В нём сложно управлять памятью, например. Нет хороших компиляторов, отладчиков, профайлеров, IDE…
                                                                                        0
                                                                                        В нём сложно управлять памятью, например.

                                                                                        А в чём сложности?


                                                                                        Нет хороших компиляторов,

                                                                                        А чем существующие плохи?


                                                                                        отладчиков, профайлеров, IDE…

                                                                                        Можете использовать ту же Visual Studio.

                                                                                          +1
                                                                                          А чем существующие плохи?

                                                                                          C++ компиляторы только-только догнали фортран по производительности кода. D ещё далёк от этого.


                                                                                          А вообще D — это мертворожденный язык (по моему скромному мнению). Он был создан для того, чтобы «починить» ошибки дизайна C++. Проблема в том, что никто не может сказать внятно, в чём именно ошибки. И тем паче как их чинить.


                                                                                          Сборщик мусора — страшная штука. D захотел «починить» проблемы с указателями в C++. Но только сборщик мусора — не решение проблем с указателями...

                                                                                            0
                                                                                            D ещё далёк от этого.

                                                                                            С чего вы взяли? Там довольно крутой компилятор, позволяющий использовать разные бэкенды, в том числе и популярные у плюсовиков GCC да LLVM.


                                                                                            Проблема в том, что никто не может сказать внятно, в чём именно ошибки.

                                                                                            В C++ много кривых мест, начиная с использования препроцессора и заканчивая UB во всех местах. В любой книжке по D об этом всём рассказывается.


                                                                                            Но только сборщик мусора — не решение проблем с указателями...

                                                                                            Конечно, поэтому вас его использовать никто не заставляет.

                                                                                              +1
                                                                                              Мне очень нравится D и очень жаль, что нет крупной корпорации, которая вкидывает газиллионы долларов в его популяризацию (надеюсь, это только пока). Но все вот эти вот @nogc и @betterC у меня вызывают легкую панику.
                                                                                                0

                                                                                                Почему? Аттрибуты функций — это вообще мощная штука, позволяющая выводить различные характеристики исходя из содержимого функций. И, наоборот, ограничивать поддерево вызовов нужной характеристикой. Того же shared и pure очень не хватает в других языках.

                                                                                    +1

                                                                                    А что не так в rust с численными расчётами?

                                                                                      –2

                                                                                      Последний раз, когда я смотрел, там, например, не было доступно "из коробки" ни комплексных чисел, ни многомерных динамических массивов с сечениями и всеми сопутствующими вещами. Новый язык без этих фич — сразу в топку. Rust не для численных расчётов создавался, в конце концов, и это влияет на вектор развития.

                                                                                        +3

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

                                                                                          –1

                                                                                          Я поэтому и написал про "новый язык". Понятно, что на C++ уже все привыкли к велосипедам. А комплексные числа там, в принципе, есть как часть стандартной бибилотеки. А с учётом стандарта C99 они ещё и частью языка являются (_Complex).

                                                                                          0

                                                                                          Да всё там есть. Да, это сторонние библиотеки, но зачем это в сам язык-то пихать?

                                                                                            0

                                                                                            Мы же про удобство для конкретных целей говорим. Так-то на любом языке можно решать любые задачи. Хоть на vanilla C. Только библиотеки подавай.


                                                                                            Вообще говоря, никак не хотел обидеть растаманов, но язык же явно с другим фокусом создавался. Системное программирование, контроллеры, веб и т.д. Не вижу, какие такие преимущества он может принести для численного моделирования по сравнению с Fortran/C++, чтобы всё бросать и разбираться во всех этих тонкостях области действия, (не)изменяемости, unsafe и прочих специфических приблуд. При этом, для элементарных, с точки зрения численных расчётов, вещей уже нужно тащить даже не стандартные, а какие-то непонятно кем написанные библиотеки, API которых может внезапано поменяться или поддержка которых вообще может прекратиться.

                                                                                              0

                                                                                              На всякий случай поясню комментарий про API: время жизни очень большой части софта для численных расчётов должно измеряться десятилетиями. Поэтому на новомодный сырой язык мало кто перейдёт только потому, что это молодёжно. Очень, очень не зря современный фортран тащит на себе ярмо совместимости с предыдущими версиями стандарта.


                                                                                              Нас, например, очень напрягает то, что современный C++ убирает кучу старых фич, т.к. это ломает код.

                                                                                                +1
                                                                                                Мы же про удобство для конкретных целей говорим. Так-то на любом языке можно решать любые задачи. Хоть на vanilla C. Только библиотеки подавай.

                                                                                                Не совсем. Некоторые вещи, отсутствующие в языке, невозможно восполнить библиотеками. В C, например, напрочь отсутствует обобщённые типы, так что при работе с матрицами разных типов там нужно либо обмазываться макросами, либо каким-то образом постоянно передавать информацию о типах и забыть о типобезопасности. А насчёт удобства — когда нужная библиотека добавляется добавлением одной строчки в конфиг проекта, разница между стандартной библиотекой и сторонней уже перестаёт быть столь существенной.


                                                                                                Не вижу, какие такие преимущества он может принести для численного моделирования по сравнению с Fortran/C++, чтобы всё бросать и разбираться во всех этих тонкостях области действия, (не)изменяемости, unsafe и прочих специфических приблуд.

                                                                                                Распараллеливание операций над матрицей с заменой по сравнению с однопоточным вариантом одной строки с гарантией отсутствия проблем с многопоточностью годится?


                                                                                                При этом, для элементарных, с точки зрения численных расчётов, вещей уже нужно тащить даже не стандартные, а какие-то непонятно кем написанные библиотеки, API которых может внезапано поменяться или поддержка которых вообще может прекратиться.

                                                                                                Стандартную библиотеку тоже непонятно кто писал, но этим людям вы почему-то доверяете.

                                                                                                  0
                                                                                                  Не совсем. Некоторые вещи, отсутствующие в языке, невозможно восполнить библиотеками. В C, например, напрочь отсутствует обобщённые типы, так что при работе с матрицами разных типов там нужно либо обмазываться макросами, либо каким-то образом постоянно передавать информацию о типах и забыть и типобезопасности.

                                                                                                  Шаблонные типы — это, безусловно, добавляет плюс в копилку rust'а, но они уже есть в C++, что сильно снижает мотивацию для переезда.


                                                                                                  А насчёт удобства — когда нужная библиотека добавляется добавлением одной строчки в конфиг проекта, разница между стандартной библиотекой и сторонней уже перестаёт быть столь существенной.

                                                                                                  Не так всё просто. По поводу библиотек — ниже.


                                                                                                  Распараллеливание операций над матрицей с заменой по сравнению с однопоточным вариантом одной строки с гарантией отсутствия проблем с многопоточностью годится?

                                                                                                  Это как раз то, что реализуется на уровне библиотек. В частности, подобные библиотеки уже очень давно есть и для C и для Фортрана (например, тот же, MKL). К тому же в контексте HPC чаще используется распараллеливание по распределённым процессам (используя MPI), а не по потокам. Хотя можно (но непросто) делать и то, и другое вместе.


                                                                                                  Стандартную библиотеку тоже непонятно кто писал, но этим людям вы почему-то доверяете.

                                                                                                  По поводу библиотек: самое главное отличие стандартной библиотеки заключается в том, что её API задан неким стандартом. Это значит, что он (интерфейс) не будет меняться по велению левой пятки его создателя. А если и будет меняться, то это будет делаться в рамках последовательного процесса (standard -> obsolete -> deleted), растянутого на годы, а иногда и десятилетия. Подобная консервативность — это именно то, что ставит древние языки на первое место при выборе инструментов для долгосрочного проекта.


                                                                                                  Сразу замечу: всё это совершенно не означает, что нужно теперь всю жизнь сидеть на Fortran/C++, игнорируя прогресс в языкостроении. В некотором смысле, я уже давно жду "ту молодую шпану", которая сметёт этих старичков. Но если посмотреть на то, что находится в разработке на данный момент, то для численных расчётов выбор, скорее, падёт на что-нибудь типа julia, чем на rust. Достаточно взглянуть на базовую библиотеку (Base) julia, с огромным количеством матфункций (которые, кстати, работают и с комплексными числами, что важно), с кучей операций над массивами (они, похоже, собрали всё, что есть в fortran'e и matlab'e на этот счёт), чтобы понять, что этот язык делали с прицелом на расчёты. Я не уверен, что даже в сторонних библиотеках rust'а найдётся большая часть того функционала, который уже сейчас есть у julia.

                                                                                                    0
                                                                                                    Распараллеливание операций над матрицей с заменой по сравнению с однопоточным вариантом одной строки с гарантией отсутствия проблем с многопоточностью годится?

                                                                                                    Если я правильно посмотрел, там по ссылке по сути заменяется обычный "map" для обхода массива на его параллельную реализацию "threaded map". Это во многих языках есть из коробки или почти из коробки — если что-то не так понял, то поясните пожалуйста.

                                                                                        0

                                                                                        Вот каким должен быть идеальный цикл — http://cl-cookbook.sourceforge.net/loop.html :)

                                                                                          0

                                                                                          А зачем это делать отдельным макросом, если это прекрасно пишется на итераторах?

                                                                                            0
                                                                                            503, хабраэффект :( Приведите тут, пожалуйста. А макросы, имхо, для использования в чистом С.
                                                                                              +1

                                                                                              Ну я ради стеба привёл эту ссылку, просто в Common Lisp loop это целый язык, сложнее самого Lisp :)


                                                                                              (loop
                                                                                                for item in list
                                                                                                for i from 1 to 10
                                                                                                do (something))
                                                                                              
                                                                                              (loop for i from 0 downto -10 collect i)
                                                                                              
                                                                                              (loop for v being the hash-values in h using (hash-key k) ...)
                                                                                              
                                                                                              (loop repeat 5
                                                                                                    for y = 1 then (+ x y)
                                                                                                    for x = 0 then y
                                                                                                    collect y)
                                                                                              
                                                                                              (loop for i in *random*
                                                                                                 counting (evenp i) into evens
                                                                                                 counting (oddp i) into odds
                                                                                                 summing i into total
                                                                                                 maximizing i into max
                                                                                                 minimizing i into min
                                                                                                 finally (return (list min max total evens odds)))
                                                                                            –1

                                                                                            Можт, писали:
                                                                                            У нас в java так:
                                                                                            collection.forEach(item -> {
                                                                                            [..]
                                                                                            });
                                                                                            Кратко и понятно

                                                                                              0
                                                                                              Я ведь не зря в самом начале статьи привёл реальный кусок кода из пяти вложенных циклов. Отдельностоящий `for (int i=0; i<size; i++)` тоже пристойно читается. Так что, жава жавой, а конкретные сценария использования в нагруженном коде приветствуются!
                                                                                                0

                                                                                                Ах вот оно что! Ну ладно, вот конкретный сценарий:


                                                                                                Нужно переделать коллекцию из Product в коллекцию из ProductDto.


                                                                                                List = products.stream().map(ProductDto::new);

                                                                                                Вроде цикл есть… но его нет. По мне, очень удобно.
                                                                                                Можно даже с map (ключ-значение).

                                                                                                  0
                                                                                                  Это ненагруженный пример :(
                                                                                                0
                                                                                                Данная конструкция не особо полезна, т.к. все возникающие в лямбде checked исключения нужно будет дополнительно оборачивать в unchecked. Почти всегда лучше написать обычный цикл.
                                                                                                  0

                                                                                                  Ну, если это коллекция например из orm, то исключений там быть не должно.

                                                                                                  0

                                                                                                  'for(var item: collection) {...}' — более краткий вариант.

                                                                                                  +1
                                                                                                  Хххех, ну вот появился и первый минус к статье, обоснование «не согласен с изложенным». А ведь основная мысль статьи заключается во фразе «научите меня» :)

                                                                                                  Не согласны — предлагайте мнение / варианты! Минусовать не стесняйтесь, но мне интересны мнения!
                                                                                                    +1
                                                                                                    Не согласны — предлагайте мнение / варианты!

                                                                                                    Казалось бы, вместо первого цикла в начале поста прямо напрашивается вынести соответствующие вещи в отдельные функции/итераторы, чтобы записывалось как-то так:


                                                                                                    for (auto iter: range(1, n_iters)) { // some iterative computation
                                                                                                        for (auto cell: mesh.cells()) // loop through all tetrahedra cells
                                                                                                            for (auto [v1, v2]: subsets(cell.vertices(), 2)) // for every pair of vertices
                                                                                                                    for (auto d: range(1, 3)) { // for each of 3 dimensions
                                                                                                                        nlRowScaling(weight);
                                                                                                                        nlBegin(NL_ROW);
                                                                                                                        nlCoefficient(v1, d,  1);
                                                                                                                        nlCoefficient(v2, d, -1);
                                                                                                                        nlEnd(NL_ROW);
                                                                                                                    }
                                                                                                        [...]
                                                                                                    }

                                                                                                    Выглядит чище и понятнее, сложнее с индексами ошибиться.

                                                                                                      0

                                                                                                      Да, именно к этому сейчас и пришли. Вы только типы забыли перед объявлением переменных.

                                                                                                        0

                                                                                                        В посте не написано, что к этому пришли — поэтому и предложил :) Про типы — да, действительно забыл (простительно т.к. не пишу на c++), добавил auto везде.
                                                                                                        По факту с индексами вообще редко приходится напрямую оперировать — в том числе в численных научных вычислениях, которые иногда пишу.

                                                                                                          0

                                                                                                          Я auto стараюсь не использовать в циклах (ну, помимо structural binding в enumerate/zip), т.к. бывает, что переменная целочисленная, а бывает, что и ссылку возвращаю. Ну и вообще auto на один символ длиннее int :)

                                                                                                            0

                                                                                                            Ну, из int'ов в моём варианте предполагается только iter и d, а cell, v1, v2 — это соответствующие структуры.

                                                                                                    +2
                                                                                                    В go цикл for с итератором выглядит так:

                                                                                                    for i, v := range arr {}
                                                                                                    

                                                                                                    Он работает и как enumerate() и как range() в python, границы можно указать через создание слайса arr[low, high, max] либо переписав цикл в классическом виде, ненужные значения можно просто закомментировать символом «_».
                                                                                                      +1

                                                                                                      Да, все таки такие большие трех-, четырех- и больше мерные проходы по матрицам, массивам и т. д. стоит выносить в отдельную, с говорящим названием, функцию. Ибо я, например, сидящий на JS, как бы не крутился, все равно получаеться громоздко и неудобно (хоть через foreach() хоть через тот же for)

                                                                                                        +1

                                                                                                        У вас конструкция из 5 вложенных циклов. Это операция такой сложности для понимания и отладки, что макросами и синтаксическим сахаром вы можете ее сделать только менее понятной для стороннего человека. У вас отличные комментарии в коде, сам он весьма читабельный. Если в первую секунду не ясно, что и как итенируется, то потом видны комментарии и все становится на свои места. Смешайте это на половину с for-range или for each и читабельность упадёт. Буквально мне не нравятся только константы 4 и пр. в цикле.

                                                                                                          0
                                                                                                          На ваш взгляд, каким должен быть совершенный цикл в 2020м году?
                                                                                                          Примерно таким, как у вас в статье, только в C++20 (23) можно использовать стандартные функции вместо самописных. range -> iota (https://gcc.godbolt.org/z/d3bqYK). enumerate и zip должны появиться в C++23, так это выглядит в range-v3 (https://gcc.godbolt.org/z/9EfMj5):
                                                                                                          #include <range/v3/view/enumerate.hpp>
                                                                                                          #include <range/v3/view/zip.hpp>
                                                                                                          
                                                                                                          #include <vector>
                                                                                                          
                                                                                                          void test(std::vector<int> xs, std::vector<float> ys) {
                                                                                                              for (auto [x, i] : ranges::view::enumerate(xs)) {
                                                                                                                  // ...
                                                                                                              }
                                                                                                              for (auto [x, y] : ranges::view::zip(xs, ys)) {
                                                                                                                  // ...
                                                                                                              }
                                                                                                          }
                                                                                                          Вместо вложенных циклов можно (но не факт что нужно) использовать cartesian_product (https://gcc.godbolt.org/z/vaasqq):
                                                                                                          void test(std::vector<int> xs, std::vector<float> ys) {
                                                                                                              for (auto [x, y] : ranges::view::cartesian_product(xs, ys)) {
                                                                                                                  // ...
                                                                                                              }
                                                                                                          }
                                                                                                            +1
                                                                                                            iota

                                                                                                            2020 год близится к концу, а в C++ так и не исчезла страсть к таинственным аббревиатурам. А потом студенты в порядке букв будут путаться.

                                                                                                              0
                                                                                                              Это не аббревиатура, а греческая буква (честно одолженная из языка программирования APL).
                                                                                                                0

                                                                                                                Посмотрел в википедии, забавно.
                                                                                                                Была какая-нибудь публичная дискуссия на тему выбора названия функции, есть где почитать? Тот же range IMHO интуитивно понятнее.

                                                                                                            0
                                                                                                            Кстати, в c++20 появился std::ranges, что ещё больше упрощает написание такой функции, но я пока не готов переходить на этот стандарт.


                                                                                                            Ну а пока есть FunctionalPlus (C++14), range-v3 (C++14/17/20) и NanoRange (C++17).
                                                                                                              –1
                                                                                                              А так for выглядит в
                                                                                                              Zig
                                                                                                              test "for basics" {
                                                                                                                  const items = [_]i32 { 4, 5, 3, 4, 0 };
                                                                                                                  var sum: i32 = 0;
                                                                                                              
                                                                                                                  // For loops iterate over slices and arrays.
                                                                                                                  for (items) |value| {
                                                                                                                      if (value == 0) {
                                                                                                                          continue;
                                                                                                                      }
                                                                                                                      sum += value;
                                                                                                                  }
                                                                                                                  assert(sum == 16);
                                                                                                              
                                                                                                                  for (items[0..1]) |value| {
                                                                                                                      sum += value;
                                                                                                                  }
                                                                                                                  assert(sum == 20);
                                                                                                              
                                                                                                                  var sum2: i32 = 0;
                                                                                                                  for (items) |value, i| {
                                                                                                                      assert(@TypeOf(i) == usize);
                                                                                                                      sum2 += @intCast(i32, i);
                                                                                                                  }
                                                                                                                  assert(sum2 == 10);
                                                                                                              }
                                                                                                              
                                                                                                              test "for reference" {
                                                                                                                  var items = [_]i32 { 3, 4, 2 };
                                                                                                              
                                                                                                                  for (items) |*value| {
                                                                                                                      value.* += 1;
                                                                                                                  }
                                                                                                              
                                                                                                                  assert(items[0] == 4);
                                                                                                                  assert(items[1] == 5);
                                                                                                                  assert(items[2] == 3);
                                                                                                              }
                                                                                                              
                                                                                                              test "for else" {
                                                                                                                  var items = [_]?i32 { 3, 4, null, 5 };
                                                                                                              
                                                                                                                  var sum: i32 = 0;
                                                                                                                  const result = for (items) |value| {
                                                                                                                      if (value != null) {
                                                                                                                          sum += value.?;
                                                                                                                      }
                                                                                                                  } else blk: {
                                                                                                                      assert(sum == 12);
                                                                                                                      break :blk sum;
                                                                                                                  };
                                                                                                                  assert(result == 12);
                                                                                                              }


                                                                                                              Замечу, что в Zig нет итераторов, но можно определить внутреннюю структуру (обычно Iterator) и c функциями next, prev и т.д. и использовать while:
                                                                                                              var it = somevar.iterator();
                                                                                                              while (it.next()) |value| {
                                                                                                              ...
                                                                                                              }

                                                                                                              В предстоящем релизе значительно улучшены compiletime-возможности (помимо прочего), так что у Zig большое будущее. :)
                                                                                                              P.S. Используется подсветка кода С++.
                                                                                                                +1
                                                                                                                Как мне кажется, хорошим является вариант с range. Только, я бы вынес всё, что Вы писали внури тела функции в отдельный класс и кроме варианта range (end) добавил бы range (begin, end) и, быть может, range (begin, end, step). Но куда более удобным вариантом будет сделать класс шаблонным. Тогда можно будет писать, например, for (auto i : range (it1, it2)).
                                                                                                                  0
                                                                                                                  У меня основная мысль введения слова range в лексикон нашего проекта именно в подчёркивания обычности цикла, это строго от 0 до n-1. Поэтому у меня строго range с одним аргументом. Если делать range(begin, end, step), это проще обычный for(;;) использовать.
                                                                                                                  0
                                                                                                                  Вот результаты моих экспериментов, когда-то тоже надо было много for’ов писать: github.com/yeswell/for-range
                                                                                                                    +1

                                                                                                                    Маленькое замечание: std::iterator уже убрали из языка. Вместо long long, наверное, логичнее использовать size_t.

                                                                                                                      0
                                                                                                                      О, про std::iterator не знал, но когда писал он точно был
                                                                                                                        0

                                                                                                                        Ну вот в частности поэтому я не очень тороплюсь переходить на >=C++20, да и из C++17 использую не всё. Что-то в последнее время комитет как с цепи сорвался.

                                                                                                                    0
                                                                                                                    Довольно банальная мысль, но я против макросов, которые дублируют и так вполне понятные конструкции языка. Эти макросы хорошо понятны Вам — вы их придумали и вы ими пользуетесь. Но для нового человека это доп нагрузка, нужно их выучить, и если код с for или range он прочитал бы сходу просто владея синтаксисом языка, то макросы придется дополнительно изучить и запомнить.
                                                                                                                      0

                                                                                                                      Именно поэтому я написал эту обёртку с range; но справедливости ради любой нормальный IDE (MS Visual Studio, например) при наведении мышки на FOR(i, n) покажет определение дефайна.


                                                                                                                      Конкретно наш код будет читаться только членами нашей команды, поэтому локальные загогулины допустимы, хотя и не очень желательны.

                                                                                                                        0
                                                                                                                        Состав команды штука не постоянная, наводить на макросы и читать определение дополнительное обременение. Лично я для себя осознал, что это действительно ненужное и усложнение, когда у нас практику студенты проходили. Они знали язык, но макросы сбивали их столку и заставляли задать лишь один вопрос — «а зачем?!», и когда я пытался объяснить по их глазам было видно что они не совсем согласны со мной. Плюс введение макроса это не только усложнение в чтении, но и в написании, теперь надо им везде пользоваться, помнить его. И обычно количество таких макросов имеет свойство расти.
                                                                                                                        Я не против макросов в целом, я против их использования в тех местах, где синтаксис языка и так неплохо справляется.
                                                                                                                      +1

                                                                                                                      Выше уже упоминали D, а если вспомнить, что все эти ranges в C++ попали оттуда (именно в виде шаблонных конструкций этапа компиляции), то и for надо смотреть там же.


                                                                                                                      foreach (i; 0..100) {}

                                                                                                                      В C++ это переносится примерно так же, как у вас в статье


                                                                                                                      for (auto i : iota(100)) {}

                                                                                                                      Я считаю, что синтаксический сахар в виде range-based for вместе с хорошей библиотекой ranges (ranges-v3, которая фактически в стандарте C++20), и есть идеальный for.
                                                                                                                      Ну и стоит упомянуть, что функциональщина в виде map, filter или cartesianProduct часто лучше читается. Можете посмотреть на ndslice и увидеть, как хорошо решается задача многомерного прохода на тех же абстракциях.

                                                                                                                        0

                                                                                                                        В D, кстати, тоже есть iota:


                                                                                                                        foreach (i; 100.iota) {}
                                                                                                                          0

                                                                                                                          Да, но 0..100 читается лучше. iota хороша для функциональных цепочек с map, filter, chunk и тд, и ещё для шага отличного от 1, он там третьим аргументом передаётся.
                                                                                                                          Имхо, это недоработка в языке, что 0..100 это только для foreach. Было бы лучше, если можно было бы в любом месте использовать для обозначения диапазонов. Вместо этого… переиспользовали для срезов и значение там совсем другое.

                                                                                                                        0

                                                                                                                        Самый лучший foreach что я видел — у Kotlin


                                                                                                                        list.forEach {
                                                                                                                           println(it)
                                                                                                                        }
                                                                                                                          0

                                                                                                                          На scala аналогом будет


                                                                                                                          list foreach println
                                                                                                                            0

                                                                                                                            А если нам нужно использовать каждый элемент несколько раз?


                                                                                                                            list.forEach {
                                                                                                                               action1(it)
                                                                                                                               action2(it)
                                                                                                                               ...
                                                                                                                            }
                                                                                                                              0

                                                                                                                              Пожалуйста:
                                                                                                                              list foreach { it=>
                                                                                                                              action1(it)
                                                                                                                              action2(it)
                                                                                                                              }
                                                                                                                              Вложенные циклы так даже удобнее:
                                                                                                                              list1 foreach { a=>
                                                                                                                              list2 foreach { b=>
                                                                                                                              use(a, b)
                                                                                                                              }
                                                                                                                              }
                                                                                                                              Но, конечно, второй случай можно записать более традиционно:
                                                                                                                              for(a<-list1; b<-list2) {...}
                                                                                                                              Kotlin задумывался как более простая scala. it-синтаксис вообще из groovy.

                                                                                                                              0

                                                                                                                              Так то ваш пример в kotlin не сильно длиннее будет


                                                                                                                              list.forEach(::println)
                                                                                                                              0

                                                                                                                              Чем этот forEach удобнее котлиновского же цикла for, да и цикла for в других языках?


                                                                                                                              list.forEach {
                                                                                                                                 println(it)
                                                                                                                              }

                                                                                                                              vs


                                                                                                                              for (it <- list) {
                                                                                                                                  println(it)
                                                                                                                              }
                                                                                                                                +1

                                                                                                                                Такой метод удобнее, когда цепочка адаптеров итераторов уже весьма длинная.

                                                                                                                              0
                                                                                                                              А почему бы, в Вашем конкретном случае, не запускать вычислания по каждому из направлений параллельно и потом индексиванно сливать их вместе. Понимаю, что немного оффтоп, но по-моему, нужно просто немного оптимизировать алгоритм.
                                                                                                                                0
                                                                                                                                В питоне часть проблем со сложенными или вложенными циклами неплохо решает библиотека itertools (там ещё много других полезных итераторов):
                                                                                                                                for i, j, k in itertools.product(range(4), range(n), range(3)):
                                                                                                                                    # do something
                                                                                                                                

                                                                                                                                Чёрт его знает, как такую штуку реализовать на C/C++, но раз тут мозговой штурм…

                                                                                                                                Ещё если в проекте много повторяющихся геометрических итераций вида тетраэдры->вершины->грани, то можно заранее создать стандартные списки индексов, по которым потом итерироваться — такой кэшированный результат itertools.product, что снимет проблемы с производительностью.
                                                                                                                                  0

                                                                                                                                  Когда-то давно этим баловался http://rsdn.org/forum/src/1560894.1
                                                                                                                                  Практика в те годы показала что добиться аналогичной генерации не так легко.
                                                                                                                                  Кроме того такой код менее понятен другим.

                                                                                                                                    0

                                                                                                                                    Очень редко пишу вложенные циклы. Только если вложенный итератор от внешнего зависит. В остальных случаях, естественно, for I, j, k in itertools.product().

                                                                                                                                    Only users with full accounts can post comments. Log in, please.