Ответ на »сообщение 119« (AVC)
___________________________

Главное же -- пока нет механизма для совмещения CASE с безопасностью типов.
(Если Вы его предложите -- будет здорово!)

Да я собственно уже предложил - если CASE будет применим для типов, то все с безопасностью типов в порядке. В Дельфи вообще нет препятствий к этому, если метакласс признать полноценным типом. Ну и считать такие константы ordinal.:)
В Обероне чуть сложнее:

CASE msg OF
  |Message: console.Writeln(msg(Message).str);
  |SleepMessage: sleep(msg(SleepMessage).amount);
  ELSE <еще чего-нибудь>
END

Хотя что если точно также как в Дельфи?

Впрочем, может оно и не стоит того - замерять надо. Ускорение программы будет ощутимым только при большом количестве сообщений.
Еще можно компилятор научить оптимизировать IF ELSEIF. Но думаю это усложнит его больше.

Ответ на »сообщение 124« (AVC)
___________________________
ASU > Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)
По крайней мере, это для них неспецифично. :)
:)
Вместе с тем, если кто-нибудь в результате (вдруг!) предложит механизм, повышающий эффективность обероновской "программной шины", то это будет иметь самое прямое отношение к ОТ
Хм... С моей точки зрения, ОТ - это "сферический конь в вакууме"... Чтобы поднять эффективность, достаточно приписать пару нолей или ввести коэффициент чего-то (ну, очень большой... коэффициент) :)
Все разговоры об инструментах (а язык программирования (даже ассемблер) - это частный случай инструмента) безотносительно области их применения - моветон... IMHO, разумеется.

Ответ на »сообщение 122« (ASU)
___________________________

Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)

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

Ответ на »сообщение 120« (4)
___________________________
При больших векторах, такая оптимизация себя оправдывает.ASU
Это интересно. На каком компиляторе пробовали?
На ассемблере... вестимо.

Ответ на »сообщение 117« (AVC)
___________________________
Но для Windows, ИМХО, это непрактично: слишком большие таблицы переходов могут потребоваться. О чем я и сказал Mirage.
Да, практичность такого вектора вызывает сомнения, тем более, при росте числа видов сообщений и... повышении разрядности :)

Вы предлашаете другой (и весьма симпатичный) способ реализации switch, но главное не меняется -- достичь эффективности поиска перехода O(1) не получается
Вы же знаете, что есть два принципиально разных способа оптимизации программ: по скорости исполнения и размерности. В пределе вектор из четырехбайтных чисел будет стремиться к... 16 Гб, для кода программы может просто не остаться места в адресном пространстве процесса... :)

Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)
Ваша идея кажется мне интересной.
Единственное -- создается впечатление, что уж слишком умным должен быть компилятор, чтобы выбрать оптимальный способ представления switch
Можно и хешировать, почему бы и нет... Что же касается построения бинарного "дерева", то этот алгоритм реализуем на макроязыке ассемблера (когда-то я его делал...), то есть, он вполне может быть реализован в компиляторе (в виде шаблона, в том числе). Но тоже самое относится и к хешированию. В принципе можно посчитать времена затрачиваемые на вычисление хеш-функции и бинарный поиск для различных N. Правда, я не думаю, что это имеет отношение к "оберон-технологиям" :)

Ответ на »сообщение 120« (4)
___________________________

Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)AVC

При каких условиях стоит обратиться?

При условии, если список констант длинный, а диапазон -- большой. :)
На мой взгляд (пока), выбор оптимального механизма реализации switch (CASE) сделает этот раздел компилятора самым интеллектуальным. :)
Но главное не в этом.
Главное, что цепочка

IF v IS T1 THEN ...
ELSIF v IS T2 THEN...
ELSE ...
END

гарантирует безопасность типов (type-safety).
Вариантный оператор WITH (как он представлен в О-2) есть надстройка именно над цепочкой IF ELSIF ELSE, а не над CASE.
Повторю: если кто-нибудь предложит типобезопасный механизм, более эффективный, чем цепочка IF ELSIF ELSE, я буду очень рад.
Мне самому не нравится не слишком высокая эффективность этой конструкции.

Ответ на »сообщение 118« (Mirage)
___________________________


Речь шла о том, что CASE эффективнее кучи проверок с IS. Даже если IS - одно сравнение.

Я против CASE ничего не имею. :)
Хотя CASE и не всегда эффективнее, чем IF ELSIF ELSE.
CASE не учитывает случаи с разной вероятностью выбора ветвей.
Кроме того, для коротких списков констант следует учитывать дополнительные накладные расходы на вспомогательные вычисления.

Главное же -- пока нет механизма для совмещения CASE с безопасностью типов.
(Если Вы его предложите -- будет здорово!)

Ответ на »сообщение 117« (AVC)
___________________________

Речь шла о том, можно ли найти адрес перехода в массиве, сгенерированном компилятором, за одно сравнение.

Речь шла о том, что CASE эффективнее кучи проверок с IS. Даже если IS - одно сравнение.

Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)

Собственно при плотности констант в CASE хеширование и происходит (должно). А при неплотном распределении - разбиение на набор плотных и т.п. ухищрения.

Ответ на »сообщение 115« (ASU)
___________________________

Да, но при условии "плотности" списка констант.
Применительно к огромному (и потому "рассеянному") количеству сообщений Windows, это неприменимо, ИМХО.

"Плотность" списка констант не является столь важным показателем. Хороший компилятор на месте switch создаст конструкцию вида:
mov eax,[message]
lea edx,msg_vector
mov ecx,cnt_items - 1
@@loop:
cmp eax,[edx + ecx * 8]
je @@run_handler
dec ecx
jns @@loop

; default handler

@@run_handler:
jmp [edx + ecx * 8 + 4]


Речь шла о том, можно ли найти адрес перехода в массиве, сгенерированном компилятором, за одно сравнение.
Что-то вроде:

msg_type -= LEAST_MSG_TYPE_IN_SWITCH;
if (0 <= msg_type && msg_type < sizeof (jmp_table) / sizeof (*jmp_table)) {
    adr = jump_table[msg_type];
    if (adr != 0)
        goto adr; /* ну, примерно так -- на ассемблере уже не наглядно... :) */
}

Принципиально, конечно, это возможно.
Но для Windows, ИМХО, это непрактично: слишком большие таблицы переходов могут потребоваться. О чем я и сказал Mirage.
Вы предлашаете другой (и весьма симпатичный) способ реализации switch, но главное не меняется -- достичь эффективности поиска перехода O(1) не получается.


Вектор обработки выглядит следущим образом:
label dword
message1, handler1 ; номер первого сообщения и адрес его обработчика
message2, handler2 ; номер второго сообщения и адрес его обработчика
...
Если компилятор "умный", то он оптимизирует обработку вектора, исходя из количества входящих в него элементов, возможно включив прямой просмотр (а не обратный, как в примере), предвыборку (prefetch) и даже отсортировав на этапе компиляции сообщения, чтобы использовать бинарный поиск. При больших векторах, такая оптимизация себя оправдывает.

Если все же стремиться к O(1), то, ИМХО, имеет смысл обратиться не к бинарному поиску, а к хешированию. :)
Ваша идея кажется мне интересной.
Единственное -- создается впечатление, что уж слишком умным должен быть компилятор, чтобы выбрать оптимальный способ представления switch.
(Может быть, я неправ. Надо подумать.)