Malcolm, во-первых, там в качестве ключей объекты, а использовать объекты типа Integer как-то нехорошо, во-вторых, мне не нравится реализация этого класса.
!eee, почему использовать Integer нехорошо? На Java SE ты вообще уже не будешь замечать разницу между Integer и int, потому что одно автоматически конвертируется в другое. Что касается Hashtable, то класс предназначен для быстрого извлечения объектов по ключу и проверки на наличие ключей, так что, по-моему, как раз то, что ты описал.
Malcolm, почему нехорошо - да хотя бы потому, что функциям нужны простые типы и приходится туда сюда гонять данные, да и весят объекты больше. (мы все-таки в MЕ, а не в SЕ ) Насчет реализации, даже если подумать, что там все "оптимизированно" (хотя с этим можно поспорить), то там все идет через объекты (функция hashCode) и код оттуда не скопируешь.
!eee, а если всё-таки скорость и память очень критичны, реализуй hash таблицы для int сам. У них и вставка, и извлечение, и удаление в среднем за О(1).
!eee, ну унаследуй класс от Hashtable и сделай там работу исключительно через int, какие проблемы-то? Насчет потребления памяти заранее ничего утверждать нельзя, нужно сначала сделать и так, и так, а потом проверять. Насчет hashCode() не очень понял, в чем проблема. Кстати, у Integer хэш - это всегда значение int, то есть два разных объекта с одним и тем же значением внутри всегда вернут одинаковый хэш.
Malcolm, хм, действительно - даже если использовать просто два массива, то выборка происходит приблизительно в 2 раза быстрее и памяти расходуется в 2 раза меньше, чем при использовании hashtable.
Неплохая статья по началу изучения java ("Начинаем с начала, или "Hello, Java World!"") - www.skipy.ru/philosophy/beginning.html . На том сайте кстати и другие статьи интересные есть
) Насчет реализации, даже если подумать, что там все "оптимизированно" (хотя с этим можно поспорить), то там все идет через объекты (функция hashCode) и код оттуда не скопируешь. 
4 июл 2010 в 14:44