Булычёв

Перечитал Булычёва, "Смерть этажом ниже". Когда-то этот роман мне не слишком нравился, я его относил уже к периоду старения. Передумал: он и правда сильно злой, но неплохой. К этому моменту Булычёв уже озлился, но ещё не растерял талант... что ли. Вернее, его талант поменялся, он стал писать натуральней, но менее чувственно.

Для сравнения, абзац про слона из старой ещё повести "Великий дух и беглецы" (на всю жизнь запомнился):
Потом он снова шел. И ему казалось, что за ним следует слон. Большой белый слон с упругим хоботом и вислыми ушами. Слон топал по песку и подгонял Павлыша. Слон был видением. Твари тоже были видением. Огонек был видением. Ничего в самом деле не существовало - только песок и вода. Вода была зеленая и добрая. В ней мягко лежать. Она понесет обратно, к кораблю, положит у люка, и Глеб Бауэр, сам, своей волей вышедший из анабиоза, подойдет, возьмет Павлыша на руки, отнесет в каюту и скажет: ты молодец, Слава, ты далеко ушел.

И вот абзац из "Смерти":
Обратно к гостинице Шубин пошел другой улицей - заблудиться было трудно, город распланировали в девятнадцатом веке по линейке. Стало теплее, и белый снег остался только во дворах. Крыши были мокрыми, тротуары и мостовые покрывала кашица, которая брызгала из-под колес набитых народом автобусов. Над очередью, что стояла за грейпфрутами, висел приклеенный к стене неровно написанный лозунг: "Защитим чистый воздух!" Борьба за чистоту окружающие среды, отраженная в лозунге, висевшем слишком высоко, чтобы его не сорвали походя, вызвала в Шубине раздражение. Он вспомнил о Борисе и ощутил сочувствие к химзаводу.
Солнце блеснуло сквозь сизые облака, и сразу же его закрыла туча. Пошел холодный дождь. Очередь покорно мокла, накрывшись зонтиками. Шубину показалось, что дождь воняет, и он пожалел, что не взял зонтика.

Что-то в его описаниях стало правдивее, но злее. Однако это всё-таки довольно интересно читать. Просто очень другой, странный Булычёв. Мне больше нравился тот, который написал "Можно попросить Нину".

Вообще, этот, второй Булычёв чем-то похож на Стругацких. Однако те никогда не были сказочниками; фантазёрами - может быть, но у них всюду сквозила, больше ли, меньше ли, эта язвительность, готовность разить, сподвигать, капать ядом по больному. Такие люди не пишут сказки, потому, что сказочнику важно доверие. В сказку веришь только тогда, когда не ждёшь грязи. Сказочники говорят о добром, чистом.
Булычёв-прежний был сказочником, а такой вот переходный Булычёв, откуда ни возьмись, оказался даже неплохим, но - просто фантастом. Даже социальным фантастом. Даже почти не фантастом уже. Странно. Хотя дальше он что-то совсем больное и неприятное писал, всё равно странно.

@темы: Книги

---

Simoun 13

Аэру - это нечто. Таких эпичных троллей днём с огнём не сыщешь. Как только она произносит что-нибудь, все вокруг давятся языками.

Не понимаю, почему её актриса больше почти нигде не играла. По-моему, после такого её должны были разбирать, как горячие пирожки, поскольку она эту роль играет на двадцать пять с плюсом.

@темы: Аниме

---

Simoun

Вообще я готовлю длинный обзорный пост по Simoun, и не хотел пока о нём писать, но тут не выдержал:

Подбитый самолёт разворачивается в воздухе вместе со своими следами дыма!
Ололо!

(Девятая серия, 6:23 - для ценителей)

@темы: Аниме

---

Рассеянный профессор

Читать наши лекции по физике - это радость! (не для того, кто сдаёт)
"Вектор p = (..) называется вектором Умова-Пойнтинга и обозначается S".

Ещё лучше следующее предложение:
"Далее, L = [r x p], а S мы сейчас вычислим".

Лучше оно тем, что ни p, ни S в нём не относятся к предыдущему предложению.

@темы: Учеба

---

На Ленте довольно интересная конференция с языковедами. Интересная тем, что языковеды отнюдь не дураки, даже очень неглупые люди. (Приятно, а то обычно строго по башоргу: "гуманитарным складом ума называют отсутствие математического").

Поспорил бы вот с чем:
Несведущим людям часто кажется, что критерием для того, чтобы считать что-то нормативным является распространенность варианта. Я сейчас утрирую, но, к примеру, если половина населения говорит "шОфер", то это не значит, что "шОфер" и следует считать правильным. Ни в коем случае! [...] Основной критерий: инновация, которая родилась в живой речи, должна обязательно быть поддержана языковыми законами, соответствовать языковым закономерностям, внутренней логике развития языка.

Языковые законы появляются из языка. Язык появляется из языковых законов. Хвост гоняется за собакой? Или в промежутке кто-то влез, и пытается определить себя судьёй языка и путь указующим?

@темы: Русский язык

---

Уминеки

Вторая арка уминек опять занудная. Отличная идея, что герой придумывает сложные "реалистичные" объяснения там, где есть простое божественное. Это втягивает зрителя в детективное соревнование: а ну-ка, сможешь ли объяснить волшебство? Сможешь доказать, что на самом деле его не было?
Но только как это предлагается делать, когда начиная со второй арки волшебство нам показывают на экране? Свободы манёвра больше нет, герой из отважного срывателя масок и разоблачителя превращается в придурка, не желающего верить в правильное решение.

Как можно ломать голову над тем, откуда взялся труп в запертой комнате, когда минуту назад мы видели, как второй труп оттуда убрали силой волшебства? Небось, и первый там по той же причине! И уже абсолютно безразличны все эти "у кого были ключи", "кто когда заходил". Да какая разница-то? Если фея могла уколдовать труп из комнаты, она могла наколдовать что угодно. Логике больше не место в этом сериале.

А если логика всё равно убита, зачем тратить время на все эти перечисления улик и алиби? Кто будет пытаться сочинить объяснение, когда там всё равно магия? Это то же самое, что запирать калитку недостроенного забора. Как будто кто-то будет пытаться её открыть!

Бред, в общем, какой-то творится

@темы: Аниме

---

Simoun

По итогам двух серий уже не могу больше терпеть и сообщаю дорогим читателям: у меня крыша едет от этого сериала.

Нестандартные ассоциации: Now and Then, Here and There (СТРАННОСТЬ); Noein (какие-то дикие машины); Фафнер (обречённость и отчаяние, хоть и не в таком кристальном сверкающем абсолюте); Май-Химе (толпы девочек; впрочем, иного сходства нет); Stellvia; X (все эти драконы чего-то там и драконы ещё чего-то там, короче, Боги, Ритуалы, Судьба и Другие Слова с Больших Букв).

"Не смотри им в лицо, иначе ты не сможешь их убивать".
"Вот и всё. Она сказала, понемногу у меня изменится голос, и груди будут становиться всё меньше... А кажется, ничего не изменилось, да?" (садится на пол, рыдает в голос)

Классическая музыка в качестве бэков. Какой-то религиозный окрас управления этими СТРАННЫМИ машинами. Неопределённость с полами ужасно ломает мозги. Т.е. ломает мозги необходимость отсоединить то, что видишь (девушку) от формального статуса (который, эхм, оставлен на личное определение зрителя).

В общем, пока я решу этот ребуса кусок, я заворот мозгов получу. Уж лучше б тут случилось что-то однозначное, после чего я либо похоронил бы сериал как вымученный бред (а поводов-то много!), либо поверил, что режиссёру правда нужно было выволакивать всю эту прорву нестандартностей и мозголомства не потому, что он на учёте и видит розовых слонов, а для художественных целей.

@темы: Аниме

---

Японский такой японский

あるひみつがある

---

О Гиассе

Кстати говоря, у Лелуша есть ровно один-единственный путь назад на телеэкраны. Этот путь -

(спойлер)

через труп Нанали. На этот раз по-настоящему.

Так что думайте, когда просите третий сезон. По-другому не будет.

@темы: Гиасс, Околоанимешное

---

Umineko etc

Я всё жду, когда этот вертающий столы главгерой додумается задать кого-нибудь вопросом, а если это ведьма, да и ещё такая, какую нельзя убить, то нафига ей чисто человеческое развлечение с негритятами? Но, по-моему, безнадёжно. В смысле, ждать безнадёжно. Я уже думал, что дело к тому идёт: в конце первой арки Батлер ляпнул что-то про "turn the chessboard", но нет - всё свелось к "вынь мне её и положь". Браво, Шерлок. Пока вы дойдёте до своих умозаключений, зрители со скуки помрут...

@темы: Аниме

---

Umineko no naku koro ni

Ну ладно, может быть, они не так плохи, как мне сначала показалось. Сортирного юмора почти нет: юмора вообще почти нет (и да, весь, какой был - сортирный, но его было мало). Ноющей Марии тоже не так много.
Не фонтан, но смотреть можно. Да, да, характеров нет, детективы из героев тупые, Мария занудная и бесит, да; я же говорю - не фонтан...

@темы: Аниме

---

Cross†Channel

Симптоматично, что патч-локализация к игрушке лежит у меня в папке Docs\mexmat\Sem8.

@темы: Аниме

---

А вот пример того, почему я сравниваю всякие там Отоме и Соракаке с Кирандиями:

(видео)

Вообще можно почти любой кусочек так вырезать, просто тут музыка красивая.

@темы: Аниме

---

Странная ситуация: иногда умеешь что-нибудь плохо, заранее об этом предупреждаешь, но получается достаточно хорошо (или предупреждённые не умеют отличить). И вот начинаешь оправдываться: "вы не смотрите, что я так сыграл, вообще я фиговенько пианино знаю, просто эту песню заучил". "Это ерунда, эту фразу я случайно перевёл, а так словарный запас японского у меня бедный".
Потом соображаешь, что выставляешь себя ещё большим дураком: решат - рисуешься.
Ну и как тут быть?

А ещё более странно, когда делаешь плохо, но этого не замечают. То ли искренне, как непрофессионалы, то ли из чувства такта. Ну и чего тут говорить? "Ну вот, типа, фигово вышло"?

И вообще, легко тем, кто не видит своих ошибок: они всю жизнь могут совершенствоваться в счастливой уверенности, что каждый раз у них всё наилучшим образом. А я только и знаю, что замечать, сколько я бездарен и как у меня всё плохо выходит.

---

Русская культура

Я писал когда-то (не могу найти) о различиях между авторами исходных произведений и наследниками, авторами фанфиков. Вкратце, первые строят новое, а вторые ссылаются на старое. Поэтому их так легко различить.

То же и с культурой. Настоящая культура в изменчивости. Настоящая "национальная идея" в том, что в головах людей. Настоящий язык - это то, как говорят. Не наоборот. Бесполезны поиски национальной идеи в давно забытом прошлом, вытаскивание на свет божий всех этих сарафанов и самоваров, бесполезны слёзы над словарём по ушедшему словесному богатству и бесполезны правила, которые идут вразрез с практикой.

Мёртвое - мертво.

В культуре, в языке, в книгах - нет поворота назад. Нельзя отменить сделанное, обернуться, дважды войти в ту же реку. Прошлое в прошлом, старорусские песни так и останутся старорусскими, и будут лишь камнем на шее культуры до тех пор, пока их по глупости будут пытаться воскресить.
Лишь когда их оставят в могиле, не забыв, но попрощавшись; лишь когда с их смертью смирятся и обернутся, взглянув вперёд - лишь тогда мечтающие о национальной идее найдут её, всегда бывшую рядом.

Да, у страны должно быть прошлое. Но оно должно быть за спиной.
Настоящее - это то, что сейчас.

---

bmg 09

Бредовенько, но смотреть можно. Всё ширится и ширится гарем главного героя.

@темы: Аниме

---

Смотрю Otome-Zwei - спойлеры!

Zwei был снят до Sifr, он очень хороший. Может, даже лучше основного сериала - хотя сравнивать тяжело, уж слишком он на него завязан.

Нового я из него извлёк вот что: бедная Нина! Всё ей неладно. По прошлому просмотру я ничего не понял, поскольку слишком огорчён был отсутствием долгожданного пейринга Сергей - Арика (и не ждите, увы). Так вот, подчёркнуто: ей опять ничего не обломилось. Сергей, который получился после потери памяти - это не тот Сергей, которого она любила. Старый остался только в дневниках. (Японцы не знают, что нехорошо читать чужие письма).

Всё-то у неё судьба кривая. Или она сама так хочет? И потому ищет причины любить и нелюбить папу одновременно? Вот это был бы забавный персонаж, и жизненный.

@темы: Аниме

---

Смотрю Otome-Sifr - спойлеры!

Ещё забавнее: Арика всё-таки наследница. Как оно укладывается, я не понимаю, но её маму с папой опознать легко. Их сумма действительно производит Арику

А так, в шифре хорошие драки но фиговенькое всё остальное. Всё-таки, с начала Май-Отоме восьмая студия сильно потеряла в сказочности и мягкости юмора, и прибавила во всяких тупых сценках и лесби-намёках. Что-то они там со сценаристами мудрят, по-моему.

И слишком мало. Папа Арики хороший, да. Мама чуть поживее стала относительно того образа, что у неё был в "Отоме". Я бы посмотрел, пожалуй, 26-серийник.

@темы: Аниме

---

Mai-Otome - спойлеры!

Пересматриваю Май-Отоме. Забавно: Арика в конце концов единственная, кто никак не наследница королевы. Хотя сначала казалось, что она и есть потерянная наследница. И кроме того, она единственная, кто мог бы править. Если внимательно смотреть, видно, что Арику подобрали не там, не так, и без Blue Sky Sapphire. Его докупили потом на чёрном рынке Артая, Мию об этом говорит. На чёрный рынок он попал, разумеется, после операции Сергея Вонга, в ходе которой он нашёл Нину - которая и есть настоящая наследница.

Почему-то Мию сама этого не понимает, и считает Арику "продолжительницей рода Алисы". Каким боком Алиса относится к Рене, которая якобы мать Арики - я не знаю. Вполне возможно, что никаким, и Мию просто врёт, называя Арику дочерью Рены - исключительно чтобы выгадать ей преференции, поскольку на самом деле Арика дочь кого-то по ветке Алисы.

Ещё очень интересный персонаж - Сергей. Мне даже кажется, что Сергей + Сома в Г00 - это тень Сергея + Нины из Отоме. Слишком много совпадений, от имени "Сергей" и капельку русской стилистики до персоналии Сомы и отношений отца и приёмной дочери. Так вот, почему Сергей в Отоме интересен - потому, что он последователен. Он влюбчив более, чем ответственен и честен более, чем влюбчив. Все его действия укладываются в эту рамку. Единственное, что я не могу расщёлкать - это его отношение к Артаю и герцогу Артайскому. Почему он на их стороне? Я понимаю, почему он отдал Нину герцогу: потому, что подчёркивал, он видит в ней лишь дочь. Могу понять, почему Нина проглотила пилюлю и согласилась: ради него. Но почему он сам? Неужели действительно любит страну? Или просто считает, что его дорога решена, и остаётся только идти по ней?

@темы: Аниме

---

Итераторы в Delphi

В ближайших нескольких постах я расскажу о занятных применениях новшеств языка Delphi. Большинство из этих новшеств появилось в предыдущих версиях, Delphi 2010 только добавила атрибуты и расширила поддержку шаблонов, но поскольку распространяются нововведения очень медленно, чуть осветить их никогда не поздно.

Итак, итераторы. Начиная, кажется, с версии 2007, в дополнение ко стандартному "for", Delphi поддерживается

следующий синтаксис...

следующий синтаксис:

for element in collection do command;

Документация говорит, что поддерживается итерация элементов массива, символов в строке, значений из набора (set), и, самое интересное, специальным образом подготовленных классов и записей. С массивами и символами всё очевидно, про наборы можно пояснить чуть подробнее:

type
  TConnectionFlag = (cfOpen, cfClientLoggedIn, cfServingRequest, cfSupportsKeepalive, cfRequiresKeepalive);
  TConnectionFlags = set of TConnectionFlag;

//Можно было сделать проще, с помощью RTTI, но пока обойдёмся так.
function FlagName(flag: TConnectionFlag): string;
begin
  case flag of
    cfOpen: Result := 'OPEN';
    cfClientLoggedIn: Result := 'LOGGED_IN';
    cfServingRequest: Result := 'SERVING_REQUEST';
    cfSupportsKeepalive: Result := 'SUPPORTS_KEEPALIVE';
    cfRequiresKeepalive: Result := 'REQUIRES_KEEPALIVE';
  else
    Result := 'UNKNOWN FLAG';
  end;
end;

procedure PrintConnectionFlags(flags: TConnectionFlags);
var flag: TConnectionFlag;
begin
  for flag in flags do
    writeln(FlagName(flag));
end;

Это пример типичного использования итерации по наборам. Без итерации пришлось бы поступать вот так:

procedure PrintConnectionFlags(flags: TConnectionFlags);
begin
  if cfOpen in flags then writeln(FlagName(cfOpen));
  if cfClientLoggedIn in flags then writeln(FlagName(cfClientLoggedIn));
  ...
end;

Мало того, что это неудобно, потребовалось бы добавлять новую строчку в процедуру всякий раз, как добавляется новый флаг в набор.

Теперь о более интересных возможностях итераторов. Допускается создавать итераторы собственным классам. Например, собственный список или TStringList могут поддерживать итерацию по элементам списка. Большинство стандартных классов её и поддерживают:

var
  d: TStringList;
  s: string;
begin
  d := TStringList.Create;
  try
    d.LoadFromFile('lines.txt');
    for s in d do
      writeln(s);
  finally
    FreeAndNil(d);
  end;
end.

Поддержку итерации можно добавить и собственному классу. Для этого нам потребуется вспомогательный класс, итератор (или енумератор, кому как больше нравится). Основной класс должен иметь функцию GetEnumerator, которая создаёт и возвращает экземпляр вспомогательного класса:

type
  TMyCollection = class
  protected
    Items: array of integer;
  public
    function GetEnumerator: TMyCollectionEnumerator;
  end;

function TMyCollection.GetEnumerator: TMyCollectionEnumerator;
begin
  Result := TMyCollectionEnumerator.Create(Self);
end;

Сам итератор должен содержать в себе функцию MoveNext, возвращающую False, если больше элементов нет, и свойство Current, возвращающее текущий элемент:

type
  TMyCollectionEnumerator = class
  protected
    Parent: TMyCollection;
    Position: integer;
  public
    constructor Create(AParent: TMyCollection);
    function MoveNext: boolean;
    function GetCurrent: integer;
    property Current: integer read GetCurrent;
  end;

constructor TMyCollectionEnumerator.Create(AParent: TMyCollection);
begin
  inherited Create;
  Parent := AParent; //сохраняем указатель на объект, который нас создал
  Position := -1;
end;

function TMyCollectionEnumerator.MoveNext: boolean;
begin
  Result := (Position < High(Parent.Items));
  if Result then Inc(Position);
end;

function TMyCollectionEnumerator.GetCurrent: integer;
begin
  Result := Parent.Items[Position];
end;

Вот и готов простейший итератор. Нельзя ли его как-нибудь улучшить? Например, любой опытный дельфист тут же заметит, что каждое использование итератора требует создания объекта, а создание объектов, мы помним, довольно медленная операция. Слава богу, можно сделать итератор рекордом. Всё, что потребуется изменить в нашем коде - убрать вызов к наследуемому Create:

type
  TMyCollectionEnumerator = record
    Parent: TMyCollection;
    Position: integer;
    constructor Create(AParent: TMyCollection);
    function MoveNext: boolean;
    function GetCurrent: integer;
    property Current: integer read GetCurrent;
  end;

constructor TMyCollectionEnumerator.Create(AParent: TMyCollection);
begin
//  inherited Create; //убрано - рекорды не поддерживают наследования
  Parent := AParent;
  Position := -1;
end;

Таким образом получаем довольно быструю итерацию по произвольному контейнеру. Можно и сам TMyCollection сделать рекордом. Особой выгоды в производительности это не даст, поскольку он создаётся лишь один раз, но если это нужно для других целей - всегда пожалуйста. На всякий случай напоминаю, как в дельфи реализованы ссылки крест-накрест. С классами:

type
  TClass1 = class;
  TClass2 = class
    MyClass1: TClass1;
  end;
  TClass1 = class
    MyClass2: TClass2;
  end;

С рекордами:

type
  PRecord1 = ^TRecord1;
  TRecord2 = record
    MyRecord1: PRecord1;
  end;
  PRecord2 = ^TRecord2;
  TRecord1 = record
    MyRecord2 = PRecord2;
  end;

Все объявления должны находиться в пределах одного блока type, при выходе за его пределы дельфи потребует разрешить не до конца определённые типы.

Очевидный вопрос: а нельзя ли вообще не создавать на итерацию ни объекта, ни рекорда? Нельзя ли просто возвращать в GetEnumerator ссылку на самого себя, если мы уверены, что итерацией будут пользоваться только по очереди?

type
  TMyCollection = class
  public
    function GetEnumerator: TMyCollection;
    function MoveNext: boolean;
    function GetCurrent: integer;
  end;

function TMyCollection.GetEnumerator: TMyCollection;
begin
  Result := Self;
end;

Правильный ответ: нет, нельзя. Дельфи автоматически уничтожает итератор после использования. Если в GetEnumerator вы вернёте основной объект, он и будет уничтожен. Сделать с этим ничего нельзя, переопределить Destroy нельзя.

Кто-то спросит, можно ли провернуть этот фокус с рекордами. Рекорды ведь не уничтожаются? Да, рекорды не уничтожаются, но с ними такие трюки и не имеют особого смысла. Не забывайте, что рекорды передаются по значению; это значит, что функция GetEnumerator возвращает не ссылку на рекорд, а целый блок данных, всё его содержимое. Вы можете, конечно, вернуть и сам вызываемый объект:

function TMyRecord.GetEnumerator: TMyRecord;
begin
  Result := Self;
end;

Это будет значить только, что вы создатите новый рекорд TMyRecord и скопируете в него всё содержимое старого. Такой подход, кстати, вполне может однажды пригодиться, например, если внутри вашего TMyRecord небольшое количество критической информации. При доступе из нескольких потоков иногда бывает выгодно не блокировать объект на всё время итерации, а скопировать его информацию для последующего перебора и сразу же освободить его.

Блокировки
Это были простые применения итераторов, а теперь перейдём к более сложным. Самое удобное в итераторах то, что они позволяют выполнять произвольный код в момент перебора. Этим мы и воспользуемся. Например, сделаем перебор потоко-безопасным. При работе с несколькими потоками любой программист выполняет перебор примерно так:

EnterCriticalSection(Sync);
try
  for i := 0 to Collection.Count - 1 do begin (* do something *) end;
finally
  LeaveCriticalSection(Sync);
end;

Упростим эту конструкцию!

function TMyCollectionEnumerator.Create(AParent: TMyCollection);
begin
  inherited Create; //положим, это класс: у рекордов нет деструкторов
  Parent := AParent;
  Position := -1;
  EnterCriticalSection(Parent.Sync);
end;

TMyCollectionEnumerator.Destroy;
begin
  LeaveCriticalSection(Parent.Sync);
  inherited;
end;

procedure EnumCollection(Collection: TCollection);
var i: integer;
begin 
  for i in Collection do begin (* do something *) end; //Collection блокируется автоматически!
end;

Здесь мы воспользовались медленными классами, поскольку нам требовался деструктор, в котором мы могли бы разблокировать объект. С рекордами сложнее, деструкторов у них нет. Можно было бы разблокировать Collection в MoveNext на последнем элементе, но нет гарантии, что итерация дойдёт до этого элемента - не забывайте, что пользователь всегда может сделать break. Таким образом, мы не можем оставлять блокировку на время жизни записи - как раз потому, что не знаем этого времени. Остаётся только делать рекорды с копированием состояния, как описано чуть выше.

function TMyCollection.GetEnumerator: TMyCollectionEnumerator;
begin
  EnterCriticalSection(Sync);
  try
    CopyStateTo(Result); //копирует состояние массива в Result. Мы сможем перебирать result, даже если сам объект к тому времени поменяется
  finally
    LeaveCriticalSection(Sync);
  end;
end;

Иногда такой подход, как я уже говорил, очень удобен - но не всегда. Часто для сохранения состояния требуется копировать весь массив, пусть даже указателей, а это крайне долго. Как жаль, что мы не можем узнать, когда Delphi уничтожает структуру... или можем?

То, что мы сейчас сделаем - это небольшое колдовство. Дельфи не вызывает деструкторов для рекордов, но она финализирует всё их содержимое, в том числе, вызывает _Release для интерфейсов. Поэтому мы создадим интерфейс, который будет освобождать блокировку по _Release.
Для начала нам потребуется переопределённая реализация IInterface:

type
  TMyGatekeeper = class(TObject, IInterface)
  protected
    Parent: TMyCollection;
    RefCnt: integer;
  public
    constructor Create(AParent: TMyCollection);
   //IInterface
    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  end;

constructor TMyGatekeeper.Create(AParent: TMyCollection);
begin
  inherited Create;
  Parent := AParent;
  Refcnt := 0;
end;

function TMyGatekeeper.QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
begin
 //реализуем стандартно
  if GetInterface(IID, Obj) then
    Result := 0
  else
    Result := E_NOINTERFACE;
end;

function TMyGatekeeper._AddRef: Integer; stdcall;
begin
  EnterCriticalSection(Parent.Sync);
  Result := InterlockedIncrement(RefCnt); //можно было и не interlocked
end;

function TMyGatekeeper._Release: Integer; stdcall;
begin
  Result := InterlockedDecrement(RefCnt);
  LeaveCriticalSection(Parent.Sync);
 //не уничтожаем объект
end;

RefCnt мы оставили только для того, чтобы не сломать случайно какие-нибудь внутренние оптимизации Delphi, которые используют это значение. Вообще говоря, можно было бы всегда возвращать единицу. Наш объект не уничтожается с падением RefCnt до нуля; его время жизни задаётся, как для обычного дельфийского объекта, ручным уничтожением. При захвате ссылки на себя он блокирует перебираемый объект, при высвобождении - разблокирует.

Теперь сама коллекция:

type
  TMyCollectionEnumerator = record
    Parent: TMyCollection;
    Position: integer;
    Gatekeeper: IInterface;
    ...
  end;

  TMyCollection = class
  protected
    Sync: TRtlCriticalSection;
    Items: array of integer;
    Gatekeeper: TMyGatekeeper;
  public
    constructor Create;
    destructor Destroy; override;
    function GetEnumerator: TMyCollectionEnumerator;
  end;

constructor TMyCollection.Create;
begin
  inherited;
  InitializeCriticalSection(Sync);
  Gatekeeper := TMyGatekeeper.Create(Self);
end;

destructor TMyCollection.Destroy;
begin
  FreeAndNil(Gatekeeper);
  DeleteCriticalSection(Sync);
  inherited;
end;

function TMyCollection.GetEnumerator: TMyCollectionEnumerator;
begin
  Result := TMyCollectionEnumerator.Create(Self);
  Result.Gatekeeper := Gatekeeper as IInterface; //коллекция блокируется
end;

Обратите внимание, что мы храним Gatekeeper как объект. Если бы мы хранили его, как интерфейс, он постоянно пребывал бы захваченным. "Умные" указатели на интерфейсы в дельфи устроены так, что автоматически вызывают _AddRef при присваивании значения переменной интерфейсного типа, и автоматически вызывают _Release при очистке этого значения.

Когда у нас спрашивают TMyCollectionEnumerator, мы пользуемся этим свойством: мы возвращаем итератор, внутрь которого кладём переменную типа IInterface. Когда мы помещаем в неё наш Gatekeeper, дельфи автоматически выполняет _AddRef, блокируя коллекцию. Когда рекорд уничтожается, дельфи автоматически финализирует запись, очищает поле Gatekeeper, и, поскольку оно было интерфейсного типа, вызывает ему _Release - и коллекция разблокируется.

Это, несомненно, очень удобный и быстрый способ. Достаточно одного объекта типа Gatekeeper на любую коллекцию; можно использовать его во множестве итераторов сразу. Он создаётся однажды, при создании TMyCollection, и почти не добавляет накладных расходов. Однако здесь есть свои подводные камни. Хотя Delphi гарантирует уничтожение рекорда-итератора, а уничтожая его, гарантирует очистку интерфейса, неизвестно, когда она это сделает. В прилагающемся коде я выполнял некоторые эксперименты, и выяснил, например, что хотя в обычных функциях итератор уничтожается сразу же по выходу из "for ... in", в основном теле консольного приложения итераторы-рекорды не уничтожаются вообще. Так что этот приём следует использовать с осторожностью.

Фильтры
Ещё одно интересное применение итераторов - фильтры. Вместо того, чтобы писать:

for i := 0 to Collection.Length - 1 do
  if Collection.Items[i].Connected and Connection.Items[i].LoggedIn and (cfSupportsKeepalive in Connection.Items[i].Flags) then begin
    ....
  end;

Хотелось бы что-то такое:

for Connection in FilterKeepalive(Connections) do begin
  ...
end;

С итераторами это легко сделать, правда, за дополнительную цену - если вы пользуетесь рекордами. Эта дополнительная цена - создание ещё одного временного рекорда. Демонстрирую:

type TKeepaliveFilter = record
    Parent: TConnections;
    function MoveNext: boolean; //выбирает следующий подходящий по фильтрам элемент
    ...
  end;

  TKeepaliveFilterFactory = record
    Parent: TConnections;
    function GetEnumerator: TKeepaliveFilter;
  end;

function FilterKeepalive(Parent: TConnections): TKeepaliveFilterFactory;
begin
  Result.Parent := Parent;
end;

function TKeepaliveFilterFactory.GetEnumerator: TKeepaliveFilter;
begin
  Result := TKeepaliveFilter.Create(Parent);
end;

Проблема здесь в том, что синтаксис дельфи жёстко требует от объекта, стоящего в правой части "for ... in" реализовывать GetEnumerator. Функция-фильтр, которую мы пишем, должна уже сама по себе создать и вернуть какой-то объект, а этот объект затем должен будет создать ещё один - енумератор. Хотелось бы, чтобы можно было в качестве енумератора использовать этот самый, созданный в FilterKeepalive объект (в конце концов, он больше низачем не нужен!). Однако с рекордами это не пройдёт по уже упомянутой причине: если мы просто вернём в GetEnumerator "Result := Self", мы на самом деле скопируем рекорд, и ничем не улучшим положение.

Другое дело - классы. Здесь никакой дополнительной стоимости не налагается:

type TKeepaliveFilter = class
    Parent: TConnections;
    function MoveNext: boolean; //выбирает следующий подходящий по фильтрам элемент
    ...
    function GetEnumerator: TKeepaliveFilter;
  end;

function FilterKeepalive(Parent: TConnections): TKeepaliveFilter;
begin
  Result := TKeepaliveFilter.Create(Parent);
end;

function TKeepaliveFilterCreator.GetEnumerator: TKeepaliveFilter;
begin
  Result := Self;
end;

Класс просто возвращает ссылку на самого себя. Если помните, для коллекции это делать запрещалось, поскольку дельфи уничтожает итератор после использования. Однако здесь нам это не просто на руку, а жизненно необходимо: кто ещё уничтожит созданный в FilterKeepalive временный класс?

Генераторы
Ещё одно интересное применение итераторов связано с тем, что нам вовсе не обязательно перебирать уже существующие объекты. Итератор может перебирать элементы, вычисляемые им же на ходу. По ссылке в примерах есть генерация чисел фибоначчи, а мы решим более практическую задачу - и более быстро (уж разумеется, без классов-фабрик и интерфейсов, упаси меня господи).

Создадим итератор, который будет возвращать нам все окна старшего уровня в системе:

for WindowHandle in TopLevelWindows do
  ShowWindow(WindowHandle, SW_HIDE); //жаль, но десктоп скрыть не получится - он это игнорирует.

Никаких проблем с этим нет, но всё же приведу код. Вначале создадим сам итератор. Он очень простой, содержит в себе весь массив найденных окон и заполняется при создании хозяином:

type
  TWindowEnumerator = record
    Handles: array of HWND;
    Position: integer;
    function MoveNext: boolean;
    function GetCurrent: integer;
    property Current: integer read GetCurrent;
  end;
  PWindowEnumerator = ^TWindowEnumerator;

Очевидно, нам потребуется фабрика, которая его создаёт:

type
  TWindowEnumeratorFactory = record
    function GetEnumerator: TWindowEnumerator;
  end;

function EnumWindowsProc(hwnd: HWND; lParam: LPARAM): BOOL; stdcall;
begin
  with PWindowEnumerator(lParam)^ do begin
    SetLength(Handles, Length(Handles)+1); //в реальной жизни, конечно, лучше приращивать блоками по 10-15 элементов
    Handles[Length(Handles)-1] := hwnd;
  end;
  Result := true;
end;

function TWindowEnumeratorFactory.GetEnumerator: TWindowEnumerator;
begin
  EnumWindows(@EnumWindowsProc, integer(@Result));
  Result.Position := -1;
end;

Вот и всё. Функция TopLevelWindows возвращает фабрику, причём для этого не требуется делать вообще никаких операций (возвращаемый рекорд выделяется автоматически). Прилагаемая программа перебирает все окна и печатает их на экране (не скрывает, не бойтесь, я ещё не такой псих).

P.S. Вообще говоря, с окнами можно было и не извращаться. Обычные массивы работают ничуть не хуже:

type
  THwndArray = array of HWND;
  PHwndArray = ^THwndArray;

function EnumWindowsProc(hwnd: HWND; lParam: LPARAM): BOOL; stdcall;
var Handles: PHwndArray;
begin
  Handles := PHwndArray(lParam);
  SetLength(Handles^, Length(Handles^)+1);
  Handles^[Length(Handles^)-1] := hwnd;
  Result := true;
end;

function TWindowEnumeratorFactory.GetEnumerator: THwndArray;
begin
  EnumWindows(@EnumWindowsProc, integer(@Result));
end;

procedure HideTopLevelWindows;
begin
  for WindowHandle in TopLevelWindows do //точно так же
    ShowWindow(WindowHandle, SW_HIDE);
end;

Ну хорошо, хорошо, хотите - файлы?

for TargetFile in EnumFiles('C:\Windows\System32\*.exe') do
  InfectFile(TargetFile);

Тут тоже совершенно спокойно можно было обойтись массивом, но мы выгадываем на том, что если в середине енумерации нам захочется сделать break - мы не совершим лишних запросов к файловой системе. Ну и вообще, массивы лишний раз не выделять. Рекорд для итерации-то выделяется в стеке, насколько я понимаю.

Заключение
В качестве приложения даю код четырёх маленьких консольных программ, иллюстрирующих кое-что из вышесказанного. Для компиляции требуется Delphi 2010, который вы можете скачать на 30 дней с сайта embarcaderro. Может быть, скомпилится и на прежних версиях, не проверял.

И ещё немного материалов:
Документация на сайте борланд.
Большая статья на английском с примерами генераторов, внешних и внутренних фильтров.
Генераторы-рекорды с подробным сравнением получающегося ассемблерного кода.

@темы: Delphi, Компьютеры