"Поток сознания" о тестировании и программировании

среда, 21 августа 2019 г.

ToDo. Заменить где возможно memoryChain на TReadOnlyBuffer

Заменить где возможно memoryChain на TReadOnlyBuffer.

ToDo. Сделать константные буфера

Сделать константные буфера.
Которые пишутся только при чтении из файла. А потом "закрываются" через VirtualProtect.
Чтобы пользователь буфера не смог его испортить.
По аналогии с sharedConstString.

Типа:

var
Buffer : TBuffer;
Processor: TSomeMemPoolProcessor;
aStream: IStream;
While true do
Buffer := TBuffer.Create(aStream);
// - создаётся буфер с фреймом из файла.
// там внутри VirtualAlloc и VirtualProtect.
// которые делают mem_readOnly
If Buffer = nil then Exit;
// - если ничего не прочитали, то выходим
Processor.DoBuffer(Buffer.AsPointer);
// - там буфер доступен только на чтение
Buffer.Free;
// - освобождаем буфер
end;// - переходим к следующему фрейму

Там естественно try..finally, чтобы буфер не тёк.

четверг, 15 августа 2019 г.

Хоккей с памятью и методами

Научился сегодня делать интерфейсы "на лету" для классов, которые не поддерживают интерфейсы "стандартным образом".

Получилось что-то типа TVirtualInterface.

Только со связыванием в Compile-Time.
Почти. Но On Demand.

Про реализацию - чуть позже напишу.

Побочным эффектом получилось, что можно отдавать класс "как интерфейс", но без лишнего подсчёта ссылок. Делегат что ли это называется.

Грубо говоря у класса получаются ДВЕ реализации IUnknown, одна с подсчётом ссылок, а другая - БЕЗ оного.

Чем то схоже с Protocol в Objective-C.

Ну и DuckTyping там где-то рядом.

Класс может выдать себя в качестве "утки, которая умеет махать крыльями".

При этом он не является IDuck или TDuck.

Построено всё на перекрытии NewInstance и распределении дополнительной памяти "за объектом". И в этой дополнительной памяти "варим" виртуальные таблицы для каждого из "интерфейсов"/protocol'ов. По образу и подобию того как это в Delphi сделано, только эта таблица инициализируется "на лету" из метода FillProtocolVMT. Туда пихаются указатели на методы нашего объекта.

Можно в принципе вообще "на лету" варить такие таблицы, совсем "onDemand". Например в QueryInterface. Только я пока не придумал зачем.

Ну и пока у меня есть ограничения на типы и количество параметров. Таких методов.

Попутно я научился цеплять к каждому классу свой менеджер памяти. С возможностью кеширования только определённого количества экщемпляров. Ну и попутно научился делать память экземпляров immutable, через virtualAlloc и virtualProtect. Экземпляры таких классов реально immutable. Они могут модифицироваться только в конструкторах и деструкторах. А во всё остальное время жизни экщемпляров - они readOnly. Доступ к полям на запись, даже "случайный" вызывает pageFault.

То есть можно делать реально константные кешируемые объекты.

Ну это функциональными языками "навеяло".

Дальше можно делать expressionOnDemand. Выражения, вычисляемые и кеширумые по мере необходимости.

Правда вся эта конструкция пока несколько "шаткая" и до конца не отлажена, но ничего. Отлажу.

Для начала могу опубликовать реализацию реально константных кешируемых строк. Эта конструкция уже отлажена. Она в производстве уже год как.