У меня основная мысль введения слова range в лексикон нашего проекта именно в подчёркивания обычности цикла, это строго от 0 до n-1. Поэтому у меня строго range с одним аргументом. Если делать range(begin, end, step), это проще обычный for(;;) использовать.
Учитывая, что у меня массивов каждый раз разное количество и каждый разного типа, я пока вижу только зип, который возвращает std::tuple для данного смещения…
Наверное, я не умею готовить фортран, но лично у меня гибкая и расширяемая база кода получается именно на цпп. Перегрузка операторов, шаблоны и прочая фигня мне сильно помогает. Компиляторы C++ наконец-то догнали фортрановские, и теперь аргумент скорости уже не работает. Наверное, всё же очень сильно зависит от того, что нужно писать. Я наш цпп код спокойно запускаю в браузере (emscripten), и мне это часто нужно. У фортрана с этим напряжёнка. Так что, чистые конечные элементы на фортране хорошо, но вокруг этого обвязки на цпп вряд ли удастся избежать. В итоге мы и FEM делаем на чистом C++.
Но повторюсь ещё раз: очень мало людей знакомы с современным фортраном, можно даже сказать что это молодой язык, как бы парадоксально это ни звучало.
Давайте забудем про три вложенных, скажем, мне нужно два вложенных для обработки изображения. Да, я могу пройтись одним линейным циклом по всем пикселям изображения, но если мне нужно каждый пиксель усреднить с его четырьмя соседями, то мне нужны индексы (i,j) для каждого пикселя. Да, я смогу их получить целочисленным делением и взятием по модулю из линейного индекса, но насколько это оправдано?
Хххех, ну вот появился и первый минус к статье, обоснование «не согласен с изложенным». А ведь основная мысль статьи заключается во фразе «научите меня» :)
Не согласны — предлагайте мнение / варианты! Минусовать не стесняйтесь, но мне интересны мнения!
Я ведь не зря в самом начале статьи привёл реальный кусок кода из пяти вложенных циклов. Отдельностоящий `for (int i=0; i<size; i++)` тоже пристойно читается. Так что, жава жавой, а конкретные сценария использования в нагруженном коде приветствуются!
Вы знаете, если отвечать предельно честно, то самый главный критерий это то, что практически никто не знает современного фортрана (например, стандарт 2018го года). Ну а вокруг этого можно навернуть всяких рассуждений о гибкости C++ и тому подобного. Лично мне удобно, что абсолютно один и тот же код может исполняться как на CPU, так и на GPU при помощи препроцессора (си/куда).
Как я и говорил, мы отказались от сложных структур данных, и все реальные данные упакованы в std::vector<>. Но поверх этих векторов у нас есть zero cost abstractions, которые облегчают разработку. Насколько я знаю (внимание, я не специалист), всякие shared pointer возможны в фортране, но это нужно конкретно над ними работать. В цпп они доступны из коробки. Так что гибкость я бы не сбрасывал со счетов.
Мне очень интересно, что вы думаете об областях примения фортрана и цпп.
Оформление для грядущих поколений это хорошо. Но для начала код нужно написать и отладить. И я вас уверяю, во время отладки этот код читается много-много-много раз.
Вы о каких вычурных конструкциях-то? У меня нет предложения реорганизовать рабкрин (простите, стандарт c++). У меня есть конкретный вопрос о том, как писать на современном c++ таким образом, чтобы это экономило усилия разработчика в рамках одной команды. То есть, о стиле программирования в рамках одного проекта. У нас текучка небольшая, и мне несложно объяснить стиль каждому новому человеку.
Фортран хорошая штука, и даже для наших целей (матмоделирование), казалось бы, должен подходить. Но при ближайшем рассмотрении оказывается, что (современный) C++ гораздо удобнее (нам) даже несмотря на то, что мы отказались от сложных динамических структур данных и всё упаковываем в большие массивы.
Маленькое замечание:
std::iteratorуже убрали из языка. Вместоlong long, наверное, логичнее использоватьsize_t.Это точно. Я пишу на C/C++ уже четверть века, и чем дальше, тем больше он меня пугает. Но внятной замены пока не вижу.
Но повторюсь ещё раз: очень мало людей знакомы с современным фортраном, можно даже сказать что это молодой язык, как бы парадоксально это ни звучало.
Это вы сильно загнули. Опыт HPC с gcc имеете?
Мы не делаем местечкового стандарта, а думаем о стиле оформления проекта, а это в любой серьёзной конторе есть.
Не согласны — предлагайте мнение / варианты! Минусовать не стесняйтесь, но мне интересны мнения!
Как я и говорил, мы отказались от сложных структур данных, и все реальные данные упакованы в std::vector<>. Но поверх этих векторов у нас есть zero cost abstractions, которые облегчают разработку. Насколько я знаю (внимание, я не специалист), всякие shared pointer возможны в фортране, но это нужно конкретно над ними работать. В цпп они доступны из коробки. Так что гибкость я бы не сбрасывал со счетов.
Мне очень интересно, что вы думаете об областях примения фортрана и цпп.