Исследовал исходники вексина, пытаясь найти хоть какие нить зацепки на компиляцию типов и прочего, меня больше интересовал процесс задержки WE, и он привёл к компоненту TlHelp32, но не суть. В общем я подумывал написать свой компилятор, да так, что бы я расходовал память с умом.
Вексорианский компилятор использует память от 0 до 8192 по индексу. Хоть и есть там такая штука как обращение extends но у меня другой подход.
Допустим objects имя setsize 1024
т.е. будет выделяться память от 0 до 1024 и это будет обрабатывать переменная массив типа lcObj[nRange] и ещё ей подобная группа.
В прошлой заметке показана не сам структер, а сама реализация. но не через массив, который делает выделение памяти. (Я о шаге выделения)
Мой компилятор будет использовать шагающий шаблон в котором будет рассчитываться дозволительные диапазоны которые допустим устанавливает setsize.
т.е. будет выделяться память от 0 до 1024 и это будет обрабатывать переменная массив типа lcObj[nRange] и ещё ей подобная группа.
В прошлой заметке показана не сам структер, а сама реализация. но не через массив, который делает выделение памяти. (Я о шаге выделения)
Мой компилятор будет использовать шагающий шаблон в котором будет рассчитываться дозволительные диапазоны которые допустим устанавливает setsize.
Выделитель памяти использует переменную LocIndexator*Id+n*[startlocN] {saved,index,free}
Если память больше или исчерпана для этого массива, то компилятор создаёт второй массив и забивает в него данные.
Проще говоря на несколько объектов он может распределить один массив в зависимости от размера каждого объекта, однако классы не могут принимать setsize по моей задумке, но классы будут разделены на два вида, принимающие объекты в себя, он их выделяемая память будет от 0 до 8192, по этому для ключа callback можно будет включить и такой вариант обработки как callback( +*Любое аттрибутивное имя*); где допустим callback( id) = cb+ClassName+id;
Если память больше или исчерпана для этого массива, то компилятор создаёт второй массив и забивает в него данные.
Проще говоря на несколько объектов он может распределить один массив в зависимости от размера каждого объекта, однако классы не могут принимать setsize по моей задумке, но классы будут разделены на два вида, принимающие объекты в себя, он их выделяемая память будет от 0 до 8192, по этому для ключа callback можно будет включить и такой вариант обработки как callback( +*Любое аттрибутивное имя*); где допустим callback( id) = cb+ClassName+id;
И это ещё не всё, почему нельзя упростить так для других операций..
WhichUnit.Handle => GetHandleId(WhichUnit)
А так же для строковых, и др. возможных: toHash, Length, toStr, toInt, toReal, Case и д.р.
WhichUnit.Handle => GetHandleId(WhichUnit)
А так же для строковых, и др. возможных: toHash, Length, toStr, toInt, toReal, Case и д.р.
PS: Я считаю в vJasse не удобным писать scope и каждый раз к нему имя для скопки.
Мой упрощенный вариант
Как генерирует:
function pak+id+action takes nothing returns nothing
// код
endfunction
function pak+id+Init takes nothing returns nothing
set ptrigger+id = CreateTrigger() // ps переменная добавляется в globals
call TriggerAddAction(ptrigger+id, function pak+id+action )
endfunction
После генерации примерно так:
code
function pak0action takes nothing returns nothing
// код
endfunction
function pak0Init takes nothing returns nothing
set ptrigger0 = CreateTrigger() // ps переменная добавляется в globals
call TriggerAddAction(ptrigger0, function pak0action )
endfunction
Кстати эмуляцию структур лучше использовать как тип locale который развернётся как, я о том, что не выделяемую как в vjasse.
struct StructVar{
int a
float b
unit u
}
struct StructVar{
int a
float b
unit u
}
local StructVar = { 0, 0., null }
Где превращается в
local integer a = 0
local real b = 0.
local unit u = null
Ведь так было удобнее, согласитесь? Для тех функций которым нужно всё время частое значение, и объявлять их постоянно это же геморрой...
Но это лишь пока моя идейка, и кстати это можно было такое провернуть и ранее. Облегчив всё в построении кода.
Возможно моя идея сейчас выглядит глупо и совсем не нужна. Ну и ладна.
Пока компилятор я не написал, но лучше бы написать на C++ или C#, но я с ними не очень с ними в ладах, но Delphi, Lazarus я легче воспринимаю. Однако они только много веса делают в exeшниках. Если разбираться в во всех деталях с лишним весом, то это ненужный геморрой. Однако за легкость бывает и своя цена. Хотя, я ищу дельные материалы по C++; Но не для того что-то там прикрутить в WE, а для своих целей.
Пока компилятор я не написал, но лучше бы написать на C++ или C#, но я с ними не очень с ними в ладах, но Delphi, Lazarus я легче воспринимаю. Однако они только много веса делают в exeшниках. Если разбираться в во всех деталях с лишним весом, то это ненужный геморрой. Однако за легкость бывает и своя цена. Хотя, я ищу дельные материалы по C++; Но не для того что-то там прикрутить в WE, а для своих целей.
Ред. Волчачка
Все равно хочется больше простоты и удобности)))
Ред. prog
ничего личного, поколение ютуба упомянуто исключительно для придания большей красочности высказыванию
Ред. Волчачка
Не-а, дело в часто-вызываемых функциях, не во всем же избавляться от скобок. Со скобками - это дело каждого. Если все бы было так одинаково, но нет. Все разное, и не может быть одинаковым -такова воля отца восьми царей мироздания.