Заменитель Indy

Не так давно открыл для себя сетевую библиотеку Synapse. Ощущения самые положительные. В отличии от монстра по имени Indy, Synapse являет собой легкую и элегантную оболочку над сетевой инфраструктурой сокетов. В настоящий момент, на ее основе, мною создаются транспортные уровни клиента и сервера XML-RPC (правда реализация на Indy, тоже предусматривается ;))

Глюкобага. Очередная...

Заколебало :( Сегодня снова столкнулся с очень неприятной багой компилятора (бага старая и ранее я ее описывал на iXBT).

Объявляем вложенный тип в записи. Пытаемся объявить поле данного типа и получаем от компилятора пламенный привет. А вот свойства объявленного вложенного типа определяются на ура. Есть workaround: объявить поле с типом допускающим приведение к объявленному, объявить свойство проблемного типа и в методах доступа (read/write) производить приведение типов (поле к свойству/свойство к полю). Дабы устранить оверхэд методов, объявить их, как  inline.

Маленькая радость

Америки я не отрою, если скажу, что с появлением динамических массивов и динамических строк жить стало легче, жить стало веселей :) Распределение памяти и управление временем жизни берет на себя компилятор, а мы можем избавится от выделения буферов средствами GetMem и ей подобным, т.к. такие массивы и строки являются по сути указателями на те самые буферы. И самое приятное, что такой буфер можно передать любой части программы без (даже временного) дублирования, т.к. компилятор использует механизм подсчета ссылок. Правда использовать такой буфер придется с приведением типа, но оно того стоит ;)

Пример:

s := 'http://www.borland.com/';
Stream.Write(Pointer(s)^, Length(s));

Борис, ты не прав!

FAQ Apache, в части о сжатии запроса/ответа XML-RPC, говорит о том, что спецификация XML-RPC запрещает использование сжатия (и где они это нашли??). Считаю необходимым прояснить ситуацию. Спецификация XML-RPC требует: чтоб тип контента (Content-Type) запроса/ответа соответствовал text/xml, имелись некоторые обязательные заголовки (User-Agent, Content-Length) и не более того. Спецификация не запрещает применения сжатия к контенту (Content-Encoding), поэтому - Apache, ты не прав!

Enumerators (for-in-do)

Одним из самых заметных нововведений BDS 2006 является внесение в язык конструкции расширяющей оператор цикла For. For <container_item> In <container> Do; Переписывать сюда кусок документации не считаю нужным, и поэтому буду краток :) Лучше реализовывать перечислители в виде advanced-records т.к. при работе с ними не требуется динамического распределения памяти, а значит, код будет работать быстрее. Плюс удобнее работать с перечислителем вручную (не нужно создавать, не нужно финалить и разрушать), в случае необходимости. Правда сделать это (реализовать записью) не всегда удается, т.к. компилятор начинает ругаться на возвращаемый тип от GetEnumerator (видимо очередная глюкобага). Удачный пример перечислителя - перебор элементов XML документа, учитывая его структуру (каждый элемент может являться и родителем и ребенком) можно создать эффективный инструмент для перебора дочерних элементов любого родителя (хоть корня, хоть любого ребенка) с возможностью полного/близкого перебора. Сам перечислитель может обладать при этом указателем текущей глубины и номером элемента относительно начала перебора.