1) По очереди будет задано новое значение.
2) Можно передать потокам указатель на класс крит. секции, либо объявить её, как глобальную переменную.
3) TAtomic, ThreadList, глобальные переменные, а также прочие решения на любой вкус и цвет.
В момент создания такого потока копируется состояние переменных внутри тела метода, которые объявлены выше конструкции launch/async. Копии переменных сразу помечаются для сборщика мусора, который имеется у контекста нового потока.
В данном примере взорвется, т.к. в x?=0 — в х запихивается временная переменная.
Если написать var x = 0, либо x ?= new(0), то нет. Но затем для х нужно будет вызвать free().
gc() собирает весь мусор, который в т.ч. лежит в стеке.
Ну да. На то это и Free, чтобы память освобождать.
Можно писать с каких угодно букв. Язык не придирчив к этому.
Как по мне, некоторые вещи, которые я реализовал являются весьма необычными, например поддержка многопоточности и всего необходимого для неё функционала прямо из коробки и без использования костылей… Но об этом я наглядно расскажу чуть позже, как найду время для написания очередной статьи.
Нельзя же рассматривать плюшки языка, не описав перед этим синтаксис языка и базовые вещи. Так что эту статью можно считать вводной… Наверное...
В отличии от других ЯП, таких как Python, Perl, JS, Ruby и т.д., сборщик мусора у моей ВМ реализован через метки, т.е. переменная помечается, как мусор сразу при объявлении. Сборщик мусора имеет на момент вызова готовый массив указателей на мусор в памяти.
Основная идея заключалась в том, что даже в нетипизированном языке сборка мусора должна лежать на плечах программиста и быть полностью ему подконтрольна. Используя gc() программист на 150% уверен где, когда и сколько памяти будет освобождено сборщиком мусора.
Также изначально затеивал такую архитектуру, как небольшую оптимизацию. Ведь сборщику мусора вообще не нужно напрягаться, чтобы исправно выполнять свою работу.
Mash — так и переводится :D
Возможно в будущем я решусь реализовать парсер с построением AST дерева.
Так уж вышло, что транслятор я писал уровнями, обвешивая код местами не нужными механизмами. Но в итоге получился рабочий код. На русском языке трудно найти стоящую документацию по написанию трансляторов. Я постараюсь это исправить, насколько мне под силу.
Вполне эффективными, если обрабатывать массив частями.
??
2) Можно передать потокам указатель на класс крит. секции, либо объявить её, как глобальную переменную.
3) TAtomic, ThreadList, глобальные переменные, а также прочие решения на любой вкус и цвет.
Мне кажется, что путаницы не будет :)
Да...
Спасибо за пояснение.
Теперь об изменениях:
— Переделал until цикл, теперь вместо него цикл whilst — можно сказать, что это копия while, только с пост-условием.
Изменения залил на github.
В данном примере взорвется, т.к. в x?=0 — в х запихивается временная переменная.
Если написать var x = 0, либо x ?= new(0), то нет. Но затем для х нужно будет вызвать free().
gc() собирает весь мусор, который в т.ч. лежит в стеке.
Да все будет, как руки дойдут… :)
Нельзя же рассматривать плюшки языка, не описав перед этим синтаксис языка и базовые вещи. Так что эту статью можно считать вводной… Наверное...
В отличии от других ЯП, таких как Python, Perl, JS, Ruby и т.д., сборщик мусора у моей ВМ реализован через метки, т.е. переменная помечается, как мусор сразу при объявлении. Сборщик мусора имеет на момент вызова готовый массив указателей на мусор в памяти.
Основная идея заключалась в том, что даже в нетипизированном языке сборка мусора должна лежать на плечах программиста и быть полностью ему подконтрольна. Используя gc() программист на 150% уверен где, когда и сколько памяти будет освобождено сборщиком мусора.
Также изначально затеивал такую архитектуру, как небольшую оптимизацию. Ведь сборщику мусора вообще не нужно напрягаться, чтобы исправно выполнять свою работу.
https://youtu.be/bTQ2zTxF68c
Возможно в будущем я решусь реализовать парсер с построением AST дерева.
Так уж вышло, что транслятор я писал уровнями, обвешивая код местами не нужными механизмами. Но в итоге получился рабочий код. На русском языке трудно найти стоящую документацию по написанию трансляторов. Я постараюсь это исправить, насколько мне под силу.