Здравствуйте, adontz, Вы писали:

A>В .Net так не бывает
Что, правда? Ладно, вот пример: открываем MSDN и смотрим на класс ObjectIDGenerator (тот самый, который используется при сериализации). Как ты его реализуешь с помощью дерева поиска?

Здравствуйте, Mab, Вы писали:

Mab>Что, правда? Ладно, вот пример: открываем MSDN и смотрим на класс ObjectIDGenerator (тот самый, который используется при сериализации). Как ты его реализуешь с помощью дерева поиска?

А зачем ObjectIDGenerator реализовывать с помошью деревьев? Предположим, что нельзя/сложно, какое это отношение имеет к оператору switch?

Здравствуйте, adontz, Вы писали:

A>А зачем ObjectIDGenerator реализовывать с помошью деревьев? Предположим, что нельзя/сложно, какое это отношение имеет к оператору switch?
Если ты поднимишься по ветке вверх, то увидишь, что я отвечал на вопрос:

Давайте думать есть ли случаи когда оператор < реализовать тяжело , а == легко.

Как решить указанную задачу с помощью деревьев, я не знаю. С помощью хештаблиц она решается просто эффективно (у каждого экземпляра ссылочного типа по умолчанию уже есть хороший GetHashCode, согласованный с ссылочным равенством).

Учитывая, что такие задачи идентификации объектов произвольного типа встречаются в .NET довольно часто, становится понятно, почему GetHashCode стал частью object. (Особенно есть учесть, что единственный способ реализации коллекции-чего-угодно в .NET 1.0 -- это полиморфный базисный класс).

Здравствуйте, vdimas, Вы писали:

V>А что, компилятор не в состоянии определить, какой подход лучше? Если у нас, например, целые или enum из непрерывного последовательного диапазона, то в этом случае как хеш, так и мап и на фиг не сдались.

Надо быть больным чтобы целочисленне значения через хэш-таблицу проталкивать. Они и так МСИЛьным cswitch-ем поддерживаются.

V>И еще, для switch по длинным строковым константам map работает лучше хеш ф-ии.

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

V> Т.е., я вообще за то, чтобы конкретную реализацию switch компилятор выбирал исходя из типов и значений констант.

Для простх типов и так все делается. Для сложных хэш-таблица идеальное универсальное решеиние.

Здравствуйте, vdimas, Вы писали:

VD>>Зачем Wolfhound хэш-таблица как раз понятно.

V>Мне не понятно.

Сядь и разберись. Там все просто.

VD>>А вот зачем нужно упорядычивание для реализации switch-а?

V>Пример Wolfhounda не имеет отношения к свичу.

Напмоню, что разговор идет о реализации switch-а и предожение реализовывать его деревьями сделанном адонцом.

V> Отношение порядка нужно для построения мапов или сортированных последовательностей.

"Мап-ф" изумительно живут на базе хэш-талиц. Только в СТЛ хватило ума азлудить в реализацию мапа по-умолчению дерево.

V> И в чем прикол ситуации, так это в том, что графах НКА в реальной жизни от вершин отходит в среднем менее десятка дуг. Именно на таких объемах сама Microsoft рекомендует использовать SortedList вместо Hashtable. Тем более присоединяюсь, т.к. ключами в этом случае являются символы — суть целочисленные значения, для которых заведомо определено отношение порядка.

Почитай вримательно код. Погляди зачем там используется хэш-таблица.

Здравствуйте, Mab, Вы писали:

Mab>Здравствуйте, adontz, Вы писали:


A>>Я говорю о другом. Есть множество программистов, которые пишут классы, которые потенциально могут использоваться в операторе switch.
A>>Какой процент из них напишет сколько-нибудь разумную хеш-функцию?
Mab>В случае, если класс не определяет deep-семантики для равенства (т.е. равенство -- это равенство ссылок), то соответвующий GetHashCode из object обеспечивает замечательное распределение, т.к. вычисляется на основе sync block index, который чуть ли не уникален в пределах домена.
Не все так хорошо
http://www.rsdn.ru/Forum/Message.aspx?mid=581480&amp;pg=1

Автор: orangy
Дата: 24.03.04

http://www.rsdn.ru/Forum/Message.aspx?mid=581480#581480

Автор: orangy
Дата: 24.03.04

http://www.rsdn.ru/Forum/Message.aspx?mid=581480&amp;pg=4

Автор: orangy
Дата: 24.03.04