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

SI>Или я чего то не понимаю?
Ну вопрос прост: "Почему в STL нет эффективных многомерных массивов?".
ОТвет Клюева мне кажется правдоподобным, а тебе, насколько я понял, нет. Возможно ты знаешь ответ получше...

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

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

J>>а компилятору откуда об этом знать?
WA>так и я об этом — пусть пользователь решает

и в каком виде ты хочешь, чтоб он решал?
если через шаблонный параметр — это вешалка для пользователей, потому что все типы перестанут быть совместимыми.

Мне бы лично подошел какой-нть специальный traits — ну так их реализации STL и сейчас вольны определить и отдать тебе на специализацию.

You will always get what you always got
  If you always do  what you always did

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

K>Бодатся с stl — пустая трата времени. Более продуктивно использовать свои велосипеды и настраивать их по своим нуждам.

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

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

J>и в каком виде ты хочешь, чтоб он решал?
J>если через шаблонный параметр — это вешалка для пользователей, потому что все типы перестанут быть совместимыми.
и да и нет — такая совместимость нужна при копировании всего контейнера или в конструкторе копирования(решаемо)
в любом случае это не самый идеальный вариант
J>Мне бы лично подошел какой-нть специальный traits — ну так их реализации STL и сейчас вольны определить и отдать тебе на специализацию.
вполне — только вот смысл? — в одной stl это заработает в другой нет. Почему бы это не включить в стандарт — или c0x это уже сделано?
по мне вполне бы подошел вариант и с указанием поведения в конструкторе — аналогично как реализован деструктор в shared_ptr. Впрочем, вероятно, здесь много подводных камней

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

J>>Мне бы лично подошел какой-нть специальный traits — ну так их реализации STL и сейчас вольны определить и отдать тебе на специализацию.
WA>вполне — только вот смысл? — в одной stl это заработает в другой нет.
Ну потому что я хочу, чтоб мой код работал с любой STL

WA>Почему бы это не включить в стандарт — или c0x это уже сделано?
Нет, не сделано. Сделаны двигающие конструкторы и type_traits из boost (там, я думаю, есть is_pod<>).
Ты ж сам понимаешь, нельзя объять необъятное.

WA>по мне вполне бы подошел вариант и с указанием поведения в конструкторе — аналогично как реализован деструктор в shared_ptr.
Не только деструктор, но и аллокатор для счетчика.

WA>Впрочем, вероятно, здесь много подводных камней
угу.
Подовостью все не ограничивается.
Например, в может быть такой под:

struct A
{
  int a,b,c,d;
  int *p;
};

где p может указывать на одну из a,b,c,d.
Вроде и под, а если переместишь — будет плохо.

You will always get what you always got
  If you always do  what you always did

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

K>Так же некоторые хорошие идеи получили отвратительную реализацию, например, аллокатор — хорошая идея, но как это реализованно? если планируется использование аллокаторов, то фактичеески любая функция должна быть шаблонной

K>

K>template <class Allocator>
K>void get_some_data(vector<double, Allocator> &result);
K>

K>это позволит использовать аллокаторы, но такую функцию уже не бросишь в cpp-файл.
K>Имхо, более правильным решением были бы базовые классы контейнера с виртуальными функциями выделения/освобождения памяти и несколько шаблонных реализаций с аллокаторами.
K>Для себя я написал велосипед постренный по таким принципам и позволяющий использовать статический буффер на борту вектора

K>

K>void get_some_data(ArrayRef<double> &result);
K>void test()
K>{
K>   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
K>   get_some_data(res);
K>}
K>

Чтото я не пойму выгоды от Вашей реализации аллокатора. По моему приведенные выше примеры функции get_some_data не эквивалентны: первую можно параметризовать аллокатором, а вторую нет. Эквивалентный второй функции пример на stl выглядит так:

template<typename T>
class  Array : public vector<T, fast_allocator<T> >
{
// c-tors
};
void get_some_data(Array<double> &result); //< функция не шаблонная
void test()
{
   Array<double> res;    //< ну 20 дублов на стеке хранить нельзя, но с горя я не помру.
   get_some_data(res);
}

По моему это просто другая реализация, без всяких плюсов или минусов. К тому же Фича хранения 20 значений на стеке сомнительна, чаще всего vector служит для хранения данных, а не для использования его как буфферного объекта. Вот стрингу это бы не повредило, кстати говоря такая оптимизация во многих реализация std::string имеется.

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

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

K>>...

SI>А почему красно-черные деревья заведомо более проигрышные чем хеш таблица? Вы уверены 100%, что std::map должен был быть обязательно построенным на основе хеш-таблиц?

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

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

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


CE>Чтото я не пойму выгоды от Вашей реализации аллокатора. По моему приведенные выше примеры функции get_some_data не эквивалентны: первую можно параметризовать аллокатором, а вторую нет. Эквивалентный второй функции пример на stl выглядит так:

ArrayRef<T> — базовый класс
Array<T,N> : ArrayRef<T> — производный класс с буффером
ArrayA<T,Allocator> : ArrayRef<T> — производный класс с аллокатором
можно напрямую наследоватся от ArrayRef<T> и переопределить виртуальные функции выделения памяти.
для передачи в функцию по ссылке используется базовый класс ArrayRef<T> поэтому можно иметь одну нешаблонную сигнатуру функции

недостатоки этой схемы: + vtbl в класс и чуть более медленный вызов виртуальных функций при изменении размера.

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

J>Объективная проблема — данные, которые могут лежать по отрицательному смещению. realloc, естественно, ничего о них не знает.

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

Интересный патерн (или хак?) — есть набор классов одной длинны, с перегруженными функциями, а данные у всех одни, и эти классы помещены в вектор. При реалоке втаб переписывается и все ОК. Пример на тему — зачем нужен виртуальный конструктор копирования.

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

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

J>>Объективная проблема — данные, которые могут лежать по отрицательному смещению. realloc, естественно, ничего о них не знает.

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

P>Интересный патерн (или хак?) — есть набор классов одной длинны, с перегруженными функциями, а данные у всех одни, и эти классы помещены в вектор. При реалоке втаб переписывается и все ОК. Пример на тему — зачем нужен виртуальный конструктор копирования.

в вектор ты их не положишь, т.к. при укладке в вектор они будут срезаны до типа указанного как аргумент шаблона.
их можно положить через placement new, но имхо такой подход уже попахивает фейлдизайном
в этой ситуации лучше иметь стековый распеределитель памяти для быстрой аллокации обьектов + массив указателей

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

K>ArrayRef<T> — базовый класс
K>Array<T,N> : ArrayRef<T> — производный класс с буффером
K>ArrayA<T,Allocator> : ArrayRef<T> — производный класс с аллокатором
K>можно напрямую наследоватся от ArrayRef<T> и переопределить виртуальные функции выделения памяти.
K>для передачи в функцию по ссылке используется базовый класс ArrayRef<T> поэтому можно иметь одну нешаблонную сигнатуру функции

K>недостатоки этой схемы: + vtbl в класс и чуть более медленный вызов виртуальных функций при изменении размера.

Хм... а ведь и правда хорошее решение. Чувствуется дух OOP/C++. Никаких подводных камней не заметно... Еслиб не было vtbl было бы вообще идеально, но, как говорится, чудес не бывает.

Более медленный вызов виртуальных функций — это не недостаток, нельзя его в таком контексте оценить, потому как функция то выполняет распределение памяти — чуть ли не самый сильный тормоз в C++. По сравнению с malloc-ом разница между прямым и виртуальным вызовом соврешенно никакая.

Честно сказать будь я единственным девелопером в проекте, я б сделал именно так. stl много кому не нравится, а я ее ее сторонник потому как она именно стандартная. Если я займусь велосипедостроительством в крупном проекте, это чтож получится — все юзают stl, а я что самый лысый штоли?

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

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

J>>Объективная проблема — данные, которые могут лежать по отрицательному смещению. realloc, естественно, ничего о них не знает.
J>>Наверняка еще можно вспомнить проблем, если подумать.

E>Мы всё ещё о буфере std::vector? Или уже о чём-то ещё? Данных по отрицательному смещению у объекта быть не может из-за того, что объекты можно складывать в массивы

ну для не-подов, опять же по стандарту, вообще не гарантируется непрерывность занимаемой ими памяти.

E>Вообще-то всё ровно наоборот, я не знаю компиляторов, у которых возникнут проблемы при бинарном перемещении вектора из shared_ptr'ов...
Что значит — не знаешь?
Ты все существующие компиляторы (и все их версии) протестировал?
У тебя есть гарантии отсутствия проблем (из документации, например, типа "мы гарантируем, что побитовое перемещение объекта всегда валидно независимо от того, под это или нет")?
Или это просто по результатам тестов?

В любом случае, никто не мешает тебе на тех компиляторах, которыми ты пользуешься, использовать realloc, если для них все работает.

You will always get what you always got
  If you always do  what you always did

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

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

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

K>>>...

SI>>А почему красно-черные деревья заведомо более проигрышные чем хеш таблица? Вы уверены 100%, что std::map должен был быть обязательно построенным на основе хеш-таблиц?

K>операция вставки гораздо дешевле в хеш-таблице т.к. не требуется балансировка дерева, поиск (и удаление) зависит от того насколько хорошо подобрана хеш функция.
K>при небольшом числе элементов разницей можно пренебречь, но при увеличении их числа map начинает безнадежно отставать.

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

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

...
K>vector<shared_ptr> — фейлдизайн. лучше использовать умный контейнер если это возможно.
Далеко не факт что 'фейлдизайн'. shared_ptr это все же shared_ptr, со своей семантикой и возможностями, например: weak_ptr и возможностью указания своего deleter'a. При необходимости последнего, использование 'умного конетйнера' практически невозможно.
Если же речь идет о производительности, а конкретно о массовом изменении счетчиков ссылок при переаллокациях, то все не так страшно:
"Starting with Boost release 1.33.0, shared_ptr uses a lock-free implementation...", для однопоточных приложений можно переключиться на версию с ++ref_count(BOOST_SP_DISABLE_THREADS). Для выделения памяти под sp_counted_base имеется возможность задействовать quick_allocator(BOOST_SP_USE_QUICK_ALLOCATOR). А вообще — профайлер все покажет.

Вот еще цитата из "Technical Report on C++ Performance":

For example, if accessing a value through a trivial smart pointer is
significantly slower than accessing it through an ordinary pointer, the compiler is
inefficiently handling the abstraction. In the past, most compilers had significant
abstraction penalties and several current compilers still do. However, at least two
compilers have been reported to have abstraction penalties below 1% and another a
penalty of 3%, so eliminating this kind of overhead is well within the state of the art.

K>...Дефолтный dictionary (std::map) использует заведомо проигрышную схему: красно-черные деревья вместо хэширования.
Какая-то конкретная реализация может быть и не совсем оптимальна. Стандартом определена только сложность отдельных операций(logarithmic/ linear/constant/etc.) Конкретная реализация остается уделом производителей.

K>Имхо, более правильным решением были бы базовые классы контейнера с виртуальными функциями выделения/освобождения памяти
Получаем vtbl сотоварищи, и лишаемся no-throw гарантии для swap.

K>...Для себя я написал велосипед постренный по таким принципам и позволяющий использовать статический буффер на борту вектора

K>

K>void get_some_data(ArrayRef<double> &result);
K>void test()
K>{
K>   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
K>   get_some_data(res);
K>}
K>

Такая же техника применяется в некоторых реализация STL строк.

K>Имхо, проблем настолько много...
Большинство озвученных — следствия преждевременной оптимизации: "для вектора с POD можно делать ресайз не инициализируя данные", "vector<shared_ptr> — фейлдизайн", "map использует заведомо проигрышную схему".

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Здравствуйте, Kluev, Вы писали:

ЮЖ>...
K>>vector<shared_ptr> — фейлдизайн. лучше использовать умный контейнер если это возможно.
ЮЖ>Далеко не факт что 'фейлдизайн'. shared_ptr это все же shared_ptr, со своей семантикой и возможностями, например: weak_ptr и возможностью указания своего deleter'a. При необходимости последнего, использование 'умного конетйнера' практически невозможно.

если в контейнере лежат обьекты с разными deleter'aми, то это явный признак фейлдизайна.

K>>...Дефолтный dictionary (std::map) использует заведомо проигрышную схему: красно-черные деревья вместо хэширования.
ЮЖ>Какая-то конкретная реализация может быть и не совсем оптимальна. Стандартом определена только сложность отдельных операций(logarithmic/ linear/constant/etc.) Конкретная реализация остается уделом производителей.
рассуждения о сферическом коне в вакууме. в реале std::map сильно проигрывает хеш таблице с хорошей хеш функцией. особенно если в качестве ключа строки.

K>>Имхо, более правильным решением были бы базовые классы контейнера с виртуальными функциями выделения/освобождения памяти
ЮЖ>Получаем vtbl сотоварищи, и лишаемся no-throw гарантии для swap.
по сравнению с получеными удобствами не велика потеря.

K>>...Для себя я написал велосипед постренный по таким принципам и позволяющий использовать статический буффер на борту вектора

K>>

K>>void get_some_data(ArrayRef<double> &result);
K>>void test()
K>>{
K>>   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
K>>   get_some_data(res);
K>>}
K>>

ЮЖ>Такая же техника применяется в некоторых реализация STL строк.
только там все зашито в класс без возможности кастомизации. кастомизировать можно аллокатор и char_traits которые никому не нужны.

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

K>Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>>Здравствуйте, Kluev, Вы писали:

ЮЖ>>...
K>>>vector<shared_ptr> — фейлдизайн. лучше использовать умный контейнер если это возможно.
ЮЖ>>Далеко не факт что 'фейлдизайн'. shared_ptr это все же shared_ptr, со своей семантикой и возможностями, например: weak_ptr и возможностью указания своего deleter'a. При необходимости последнего, использование 'умного конетйнера' практически невозможно.

K>если в контейнере лежат обьекты с разными deleter'aми, то это явный признак фейлдизайна.
А в чем тогда принципиальное отличие от объектов с 'virtual void release()' или с виртуальным деструктором?

K>>>...Дефолтный dictionary (std::map) использует заведомо проигрышную схему: красно-черные деревья вместо хэширования.
ЮЖ>>Какая-то конкретная реализация может быть и не совсем оптимальна. Стандартом определена только сложность отдельных операций(logarithmic/ linear/constant/etc.) Конкретная реализация остается уделом производителей.
K>рассуждения о сферическом коне в вакууме. в реале std::map сильно проигрывает хеш таблице с хорошей хеш функцией. особенно если в качестве ключа строки.
Без упоминания строк это тоже был сфероконь... Мне, например, куда важнее асимптотика различных операций чем разница констант в O-нотации. Имхо, первоочередные(при возможности) оптимизации — это смена алгоритмов с квадратичных на линейные или логарифмические, например. Это дает куда больший выигрыш чем оптимизация самих этих алгоритмов. Потом уже можно и профайлер подключать, аллокаторы менять и т.п.

K>>>Имхо, более правильным решением были бы базовые классы контейнера с виртуальными функциями выделения/освобождения памяти
ЮЖ>>Получаем vtbl сотоварищи, и лишаемся no-throw гарантии для swap.
K>по сравнению с получеными удобствами не велика потеря.
no-throw swap не велика потеря ?

K>>>...Для себя я написал велосипед постренный по таким принципам и позволяющий использовать статический буффер на борту вектора
...
ЮЖ>>Такая же техника применяется в некоторых реализация STL строк.
K>только там все зашито в класс без возможности кастомизации. кастомизировать можно аллокатор и char_traits которые никому не нужны.
А что в строках нужно кастомизировать ? Строки это вообще вещь такая... неоднозначная. каждому надо что-то свое кастомизировать.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Здравствуйте, Kluev, Вы писали:

K>>Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>>>Здравствуйте, Kluev, Вы писали:

ЮЖ>>>...
K>>>>vector<shared_ptr> — фейлдизайн. лучше использовать умный контейнер если это возможно.
ЮЖ>>>Далеко не факт что 'фейлдизайн'. shared_ptr это все же shared_ptr, со своей семантикой и возможностями, например: weak_ptr и возможностью указания своего deleter'a. При необходимости последнего, использование 'умного конетйнера' практически невозможно.

K>>если в контейнере лежат обьекты с разными deleter'aми, то это явный признак фейлдизайна.
ЮЖ>А в чем тогда принципиальное отличие от объектов с 'virtual void release()' или с виртуальным деструктором?

Умный конетйнер может вызывать либо деструктор либо release. т.е. что-то одно. когда ты сказал что deleter-ы круче
очевидно предположить, что там "деструкторы" идут в перемешку с release.

ЮЖ>Без упоминания строк это тоже был сфероконь... Мне, например, куда важнее асимптотика различных операций чем разница констант в O-нотации. Имхо, первоочередные(при возможности) оптимизации — это смена алгоритмов с квадратичных на линейные или логарифмические, например. Это дает куда больший выигрыш чем оптимизация самих этих алгоритмов. Потом уже можно и профайлер подключать, аллокаторы менять и т.п.

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

K>>>>Имхо, более правильным решением были бы базовые классы контейнера с виртуальными функциями выделения/освобождения памяти
ЮЖ>>>Получаем vtbl сотоварищи, и лишаемся no-throw гарантии для swap.
K>>по сравнению с получеными удобствами не велика потеря.
ЮЖ>no-throw swap не велика потеря ?
Для одинаковых классов no-throw выполняется, к тому же обычно свап для векторов используют как move.
Надо просто писать вот так и будет щастье:

struct Test
{
    vector<int> m_vec;

    void capture(vector<int> &vec)
    {
        swap(m_vec, vec);
        vec.clear();
    }

    typedef Array<int,16> MyArray;
    MyArray m_arr;

    void capture(MyArray &arr)
    {
        swap(m_arr, arr);
        arr.clear();
    }

    void fetch(ArrayRef<int> &res)
    {
        res.push_back(12345);
    }

    void test()
    {
        Array<int,10> res;
        fetch(res);
    }
};

K>>>>...Для себя я написал велосипед постренный по таким принципам и позволяющий использовать статический буффер на борту вектора
ЮЖ>...
ЮЖ>>>Такая же техника применяется в некоторых реализация STL строк.
K>>только там все зашито в класс без возможности кастомизации. кастомизировать можно аллокатор и char_traits которые никому не нужны.
ЮЖ>А что в строках нужно кастомизировать ? Строки это вообще вещь такая... неоднозначная. каждому надо что-то свое кастомизировать.
внутренний буфер, например, кастомизировать нельзя. может у меня все строки размером гораздо больше чем этот буффер и смысла в нем для меня нет.

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

J>ну для не-подов, опять же по стандарту, вообще не гарантируется непрерывность занимаемой ими памяти.
Да, а что для таких объектов возвращает sizeof, например? Или что должен вернуть operator new?
Можешь привести примеры реализаций, где будут такого рода проблемы? Или хотя бы идеи таких платформ и реализаций?

Просто некоторые требования стандарта проистеккают из понятных особенностей тех или иных платформ, например запрет присваивать невалидные указатели или double вполне разумен.
А какие проблемы могут быть с размещением не POD'ов в памяти? Можешь привести хотя бы идею проблем?
В частности, насколько я понимаю стандарт гарантирует, что объект, созданный по new будет размещён начиная с адреса, который вернт operator new и будет занимать не более sizeof байт...
Понятно, что объет может содержать указатели внутрь себя, в том числе и неявные, но если он этого не делает, и нет указателей на объект или его внутренности где-то снаружи (что, AFAIK, запрещено семантикой std::vector), то его, по идее, можно перемещать бинарно...

E>>Вообще-то всё ровно наоборот, я не знаю компиляторов, у которых возникнут проблемы при бинарном перемещении вектора из shared_ptr'ов...
J>Что значит — не знаешь?
То и значит, что компиляторов знаю много, под много платформ, а проблемы такой не знаю. И даже идей не имею из чего она могла бы проистечь...
Вот интересуюсь у коллег, может кто знает в чём может юыть источник геморра? Или это таки в комитете перебдели?

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

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

SI>Хэш таблицы, имхо, довольно специализированное решение, т.к. придется задуматься о размере таблицы, выборе хеш-функции, возможном числе коллизий и алгоритмах их разрешения. Для обобщенной реализации (опять же, имхо) деревья — это самое то.

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

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

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

SI>>При небольшом числе элементов хэш-таблицу использовать неразумно, т.к. сразу придется выделять память для всей таблицы. Вообще говоря для небольшого количества элементов разумнее использовать отсортированный массив, однако если говорить про некий общий случай деревья являются компромиссом.
E>Можно экспоненциально наращивать размер таблицы, при заполнении, например...

А можно пример такой расширяющейся таблицы? Мне вот просто интересно как она работает... Как использовать хэш в такой таблице (хэш обрезается по разному что ли ) А как коллизии разрешать?
Неужели и для 10-100 элементов можно будет использывать?