Комментарии 14
корутина не может иметь variadic template в списке аргументов
Нет такого ограничения
В опросе не хватает пункта «Фича возможно и норм, но уже не надо».
Хорошая фича, но в реализации С++ как всегда какая-то не очень понятная. Какие-то магические методы, имена которых скорее всего вшиты в компилятор. Не чувствуется прозрачность и универсальность…
В boost уже давно есть корутины. В документации имеется немного теории, в частности сказано что корутины бывают стековые и безстековые, симметричные и асимметричные. Если С++ претендует на низкоуровневость и универсальность, хотелось бы иметь механизм реализации любых корутин. Далее, если уж здесь используется работа со стеком и переключение контекста, то начинать нужно именно с этого — вводить в язык механизмы универсальной работы со стековым контекстом. А это и стековые фреймы для исключений, и доступ к информации о вызванных функциях.
В boost уже давно есть корутины. В документации имеется немного теории, в частности сказано что корутины бывают стековые и безстековые, симметричные и асимметричные. Если С++ претендует на низкоуровневость и универсальность, хотелось бы иметь механизм реализации любых корутин. Далее, если уж здесь используется работа со стеком и переключение контекста, то начинать нужно именно с этого — вводить в язык механизмы универсальной работы со стековым контекстом. А это и стековые фреймы для исключений, и доступ к информации о вызванных функциях.
Это все нужно чтобы соблюсти принцип you don't pay for what you don't use
Мысли классные! Но всё-таки поспорю. Например, ключевые слова, названия операций тоже вшиты в компилятор, тут ничего страшного нет, я думаю.
Кажется, что этот реализованный ассиметричный механизм вполне универсален. Но у него есть особенность. Он не для конечного пользователя. Т. е. это подкапотная, к которой нужно добавить библиотечный интерфейс. И уже этот интерфейс позволит просто реализовать любые корутины, какие вам нужны.
Низкоуровневость уже давно не главный приоритет для комитета. Посмотрите, например, на std::async. Низкий уровень не всегда возможен — он может конфликтовать с другими принципами. И зачатую багоопасен. Он как goto вместо привычных for, while.
Кажется, что этот реализованный ассиметричный механизм вполне универсален. Но у него есть особенность. Он не для конечного пользователя. Т. е. это подкапотная, к которой нужно добавить библиотечный интерфейс. И уже этот интерфейс позволит просто реализовать любые корутины, какие вам нужны.
Низкоуровневость уже давно не главный приоритет для комитета. Посмотрите, например, на std::async. Низкий уровень не всегда возможен — он может конфликтовать с другими принципами. И зачатую багоопасен. Он как goto вместо привычных for, while.
Из сложившейся ситуации есть три выхода:
4-ий не использовать самые последние нововведения стандарта, а подождать пока всё испортят, продолжая использовать старые проверенные методы. Предыдущие версии ведь тоже были полны по Тюрингу.
Когда в стандартной библиотеке появятся что-то реально полезное что можно сразу применять на практике. Работа с файлами настроек, да хотя бы с командной строкой, сжатие данных, работа с мультимедийными данными, звуком, растровыми картинками, даже банальной геометрией.
Не говоря уже о нормальных способах отделения части кода в динамические библиотеки (например с оптимизацией под разные архитектуры SSE4,AVX,AVX512...).
Brainfuck тоже полный по Тьюрингу, но никто не разрабатывает на нём всерьёз. Это говорит о том, что когда код пишет и поддерживает человек, формальных критериев недостаточно. Тут решает в том числе психология:
Чем примитивнее средства вы используете, тем больше кода вам нужно написать для получения программы такой же эффективности. Тем менее выразительным он будет и тем проще в нём допустить невыявляемую ошибку.
- Количество кода (скорость его написания)
- Простота кодирования (насколько сложно придумать корректный код)
- Эффективность (насколько быстро работает программа)
- Выразительность кода (насколько сложно понять, что он делает и убедиться в корректности)
- Пространство для ошибок (насколько просто допустить ошибку, которая не будет выявлена компилятором)
Чем примитивнее средства вы используете, тем больше кода вам нужно написать для получения программы такой же эффективности. Тем менее выразительным он будет и тем проще в нём допустить невыявляемую ошибку.
Вот если взглянуть на современный C++ то по всем вашим пунктам, короме может быть эффективности и то не всегда. C++ доставляет больше проблем чем их решает.
Тут дело не примитивности средства, а в излишней его переусложнённости в местах которые не так уж и важны. И полное отсутствие внимания к средствам помогающим строить большие программы эффективнее. А именно изолировать и отделять код, накладывать ограничения на отдельные части программы и т.п.
ps: во всея языках сопрограммы это просто (даже в C), но у c++ особый путь.
Тут дело не примитивности средства, а в излишней его переусложнённости в местах которые не так уж и важны. И полное отсутствие внимания к средствам помогающим строить большие программы эффективнее. А именно изолировать и отделять код, накладывать ограничения на отдельные части программы и т.п.
ps: во всея языках сопрограммы это просто (даже в C), но у c++ особый путь.
Усложение языка видно, не поспорю. Но не соглашусь в том, что новые стандарты не решают проблемы, описанные в предыдущем комментарии.
Скорее видна другая тенденция: отделение «жизненного» кода, который возникает в повседневном программировании, от библиотечного, который пишется один раз, и который понимать каждому программисту не обязательно.
На мой взгляд, при наличии библиотечных функций (которые нам обещают), современный C++ позволяет писать эффективный код просто, выразительно и безопасно. Да, новые синтаксические конструкции нужно знать — но лишь то, что предназначено для повседневных нужд.
Скорее видна другая тенденция: отделение «жизненного» кода, который возникает в повседневном программировании, от библиотечного, который пишется один раз, и который понимать каждому программисту не обязательно.
На мой взгляд, при наличии библиотечных функций (которые нам обещают), современный C++ позволяет писать эффективный код просто, выразительно и безопасно. Да, новые синтаксические конструкции нужно знать — но лишь то, что предназначено для повседневных нужд.
Сопрограммы это же основное средство C# (называются итераторы-энумераторы). Именно там они впервые были возрождены после десятилетий забвения. Ну а Питон появился позднее.
У вас что-то с памятью. В C# генераторы появились в 2005 году, в то время как в Питоне генераторы есть с 2001 года
Возможно, вы путаете их с синтаксисом async/await, который и правда начал своё шествие по языкам программирования с C#.
-
Я всё жду, когда std::string будет не как python2 bytes array, а как python3 unicode string, чтобы iconv/icu были "из-коробки".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандарт C++20: обзор новых возможностей C++. Часть 5 «Корутины»