Так и есть. Мне представляется что такой С++ компилятор компилировал бы всю программу в машинные коды, которые не использовали бы стек. То есть фактически все бы выполнялось бы, условно, в функции main(), и обязательно с использованием goto, без использования call/ret (стека), условно, все бы инлайнилось в main(). То есть stackless-корутины. Корутиновые фреймы эмулирующие стек выделялись в куче. Ну и этих точек входы было бы по числу ядер (например, 8 потоков). Отдельно стоял бы вопрос линковки бы с внешними функциями, других языков (скорее всего и проще запретить). Но вы это описали кратко емко.
Почти ничего не понял из того что вы написали. Но я как раз не предлагаю чтобы эту "сложность" за нас решала ОС. Силами ОС ее решить не удастся (медленное переключение контекста, переход в kernel space), а именно решать компилятором. Не языковыми средствами, а именно правильной кодогенерацией на уровне компилятора.
Странно. Я тоже в школе в 11-м классе писал на 8086 («Мазовия» у меня была) тоже тетрис. Правда не против компьютера, а просто был тетрис, с возможностью игры компьютера. Вроде бы использовал несложный алгоритм, работал он очень быстро, и можно было выставить скорость («сложность») тетриса очень высокой — компьютр все равно справлялся. Писал на Turbo Pascal. Но фигуры можно было вращать, как в обычном тетрисе. По-моему, перебирались все возможные комбинации (4 поворота * число смещений), так как стакан сам по себе не очень широкий, ну, скажем комбинаций 20-30 по ширине, с учетом вращений, давало где-то 80-120 комбинаций всего. И для каждой комбинации считалась штрафная функция — чем меньше она, тем выгоднее позиция. Там, кажется, штраф был за «закрытый» пузырь внутри, за «открытый» пузырь штраф был меньше. Детали уже не помню. Но работало практически моментально — даже на 8086 перебрать 120 комбинаций — не проблема.
1. Используется, но пока релиза с использованием этого инструмента не было. Готовимся.
2. Для своих целей нам вроде бы пока хватает, но хотелось бы иметь C# обертки. Да, и значений по-умолчанию в методах и функциях не хватает, правда, вышли из положения при помощи перегрузки. Может еще что-то забыл, чего не хватает.
Есть такое. Еще сейчас возникла идея проекта (как дополнение к Beautiful Capi, возможно в отдельном репозитарии) на основе Clang по парсингу исходных кодов и генерации XML\DSL с описанием публичного API.
Да, я являюсь автором этого проекта, плюс еще несколько контрибьюторов. Следующий этап — написание полноценного руководства на русском и английских языках. Не знаю, можно ли одновременно выложить руководство на русском в github и как статью на хабре (после завершения работы над ним)?
Да, передача информации об исключении через первый аргумент. Там структура, код исключения и указатель на объект исключения. Затем на стороне клиента эта структура анализируется, и выбрасывается исключение повторно. Но уже тип исключения другой — оберточный класс, соответствующий реализационному классу. Релизован механизм перехвата (catch) исключения по типу базового класса исключения (наследование исключений)
Так и есть. Мне представляется что такой С++ компилятор компилировал бы всю программу в машинные коды, которые не использовали бы стек. То есть фактически все бы выполнялось бы, условно, в функции main(), и обязательно с использованием goto, без использования call/ret (стека), условно, все бы инлайнилось в main(). То есть stackless-корутины. Корутиновые фреймы эмулирующие стек выделялись в куче. Ну и этих точек входы было бы по числу ядер (например, 8 потоков). Отдельно стоял бы вопрос линковки бы с внешними функциями, других языков (скорее всего и проще запретить). Но вы это описали кратко емко.
да, у меня тоже такая мысль возникала когда писал
Нет, в моем понимании "виртаульные" треды могут и при помощи стеклесс корутин быть реализованы при правильной кодогенерации компилятора.
Почти ничего не понял из того что вы написали. Но я как раз не предлагаю чтобы эту "сложность" за нас решала ОС. Силами ОС ее решить не удастся (медленное переключение контекста, переход в kernel space), а именно решать компилятором. Не языковыми средствами, а именно правильной кодогенерацией на уровне компилятора.
Это вы про котлин, яву, но не про плюсы?
А почему стеклесс корутины в виде виртуальных тредов обязательно должны добавлять новую сущность в язык?
synchronized-блоки это в java или под этим что-то подразумевается в плюсах?
не знал
2. Для своих целей нам вроде бы пока хватает, но хотелось бы иметь C# обертки. Да, и значений по-умолчанию в методах и функциях не хватает, правда, вышли из положения при помощи перегрузки. Может еще что-то забыл, чего не хватает.