Здравствуйте, Аноним, Вы писали:

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

Если мине не изменяет память, то даже в MFC такая есть...
А вообще-то в чём проблемы сузить хэш? Нужно просто как-то отобразить n к 1, например популярны бывают всякие волшебные манипуляции с битами, или остаток от деления на размер таблицы, правда тогда размер таблицы обычно как простое число выбирают...

Erop пишет:

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

А че за наезды на Степанова не по делу — hash_map чем-то не устраивает
что ли?

Здравствуйте, Аноним, Вы писали:

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

хеш никогда не обрезается, просто индекс в таблице считается как hash%table_size.
а при изменении размера элементы переносятся в новую таблицу с новыми индексами.

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

K>...
K>хеш никогда не обрезается, просто индекс в таблице считается как hash%table_size.
K>а при изменении размера элементы переносятся в новую таблицу с новыми индексами.

Но раз такая пъянка — сложно сказать что выгодней. При таком подходе балансировка дерева (которая по статистике бывает не чаще чем в 2-3 вставки) может показаться достаточно выгодной операцией

Или у вас есть конкретные цифры резльтатов экспериментов? Было бы любопытно взглянуть...

Здравствуйте, Аноним, Вы писали:

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

K>>...
K>>хеш никогда не обрезается, просто индекс в таблице считается как hash%table_size.
K>>а при изменении размера элементы переносятся в новую таблицу с новыми индексами.

А>Но раз такая пъянка — сложно сказать что выгодней. При таком подходе балансировка дерева (которая по статистике бывает не чаще чем в 2-3 вставки) может показаться достаточно выгодной операцией

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

А>Или у вас есть конкретные цифры резльтатов экспериментов? Было бы любопытно взглянуть...
возьми сам и померяй, хотябы на стандартном stl

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

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

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

Ты б не позорился со своей безграмотностью, вставка в hash table дешевле не из-за балансировки (RB-деревья требуют при вставке не более одного вращения), а потому что вставка в hash table занимает константное время, в то время как вставка в дерево требует логарифмического поиска места вставки. У дерева просто другие плюсы, типа отсортированность, гарантия логарифмичности вставки (в то время как в hash table константность амортизированная, ибо может возникнуть необходимость расширения таблицы). Короче нефиг сравнивать апельсины с яблоками.

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

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

J>>ну для не-подов, опять же по стандарту, вообще не гарантируется непрерывность занимаемой ими памяти.
E>Да, а что для таких объектов возвращает sizeof, например? Или что должен вернуть operator new?
А стандарт почитать? Он возвращает размер элемента массива, если тебе вздумается сложить эти объекты во встроенный массив.
А new вообще возвращает указатель
E>Можешь привести примеры реализаций, где будут такого рода проблемы? Или хотя бы идеи таких платформ и реализаций?
Интерпретатор С++, например.
Представь, что у тебя все объекты складываются компилятором куда-то в одному ему ведомое место (c целью последующей сборки мусора, например), а пользователю отдаются только типизированные хэндлы, все размером с long, независимо от того, сколько там данных в каждом объекте, ну и хранятся обратные указатели на все имеющиеся хэндлы.
Так что если ты хэндл физически переместишь, таблица обратных указателей станет невалидной (она апдейтится при вызове конструкторов/деструкторов).

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

E>Или это таки в комитете перебдели?
В комитете, вообще-то, как раз разработчики компиляторов и сидят

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

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

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

char buffer[sizeof( T )];
delete new( buffer )T;

не валиден?

E>>Можешь привести примеры реализаций, где будут такого рода проблемы? Или хотя бы идеи таких платформ и реализаций?
J>Представь, что у тебя все объекты складываются компилятором куда-то в одному ему ведомое место (c целью последующей сборки мусора, например), а пользователю отдаются только типизированные хэндлы, все размером с long, независимо от того, сколько там данных в каждом объекте, ну и хранятся обратные указатели на все имеющиеся хэндлы.
J>Так что если ты хэндл физически переместишь, таблица обратных указателей станет невалидной (она апдейтится при вызове конструкторов/деструкторов).
Боюсь, что такая реализация не будет соответсвовать стандарту. По крайней мере будут большие проблемы с адресной арефметикой и с возможностью прекращать существование объета, путём разрушения или переиспользования хранилища. Да и вообще с самим по себе понятием storage для объекта этот подход не совсем совместим, IMHO. С new размещения, с массивами. С моделью памяти, опять же, будут проблемы, IMHO.
Скажем как ты будешь обрабатывать ситуацию, при которой ты создаёшь объект по new размещениея, а памячть в твоём "теневом хранилоище объектов" закончилась?
Кроме того такой подход, скорее всего ещё и не целесообразен. Для POD это всё вообще не годится, так как про размещение POD в памяти всё описано явно. Так что в реализации С++ по любому прийдётся иметь традиционную реализацию размещения объектов в памяти. А тогда и не понятно зачем бы тогда отдельный огород городить с не POD типами...

E>>В частности, насколько я понимаю стандарт гарантирует, что объект, созданный по new будет размещён начиная с адреса, который вернт operator new и будет занимать не более sizeof байт...
J>да, вопрос только в том, как понимать "размещен по адресу". Я это понимаю как "этот адрес можно разыменовать и обращаться к членам".
Нет, любой указатель можно привести к const char* и получить доступ к бинарному представлению данных...

J>см. выше пример с хэндлами. Все в рамках семантики.
Не годится пример с хэндлами. Он не будет соответсвовать стандарту во многих местах. Да и с многими программами будет несовместим, очевидно. Кроме того, AFAIK, таких реализаций интерпретаторов С++ нет. Что, IMHO, и не удивительно...

E>>Или это таки в комитете перебдели?
J>В комитете, вообще-то, как раз разработчики компиляторов и сидят
Ну перебдеть-то это не мешает? С невозможностью двигать содержимое std::vector по памяти перебдели же?

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

S>А че за наезды на Степанова не по делу — hash_map чем-то не устраивает
S>что ли?
Да не устраивает. Тем, что в станадарт не попал...

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

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

S>>А че за наезды на Степанова не по делу — hash_map чем-то не устраивает
S>>что ли?
E>Да не устраивает. Тем, что в станадарт не попал...

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

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

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

J>уже попал.
Ещё не уже попал
J>А тогда они просто не успевали.
Ну вполне повод для претензий, что надобаляли всяких "меганужных" в стандарте next_permutation, vector<bool> и вектор значений, который я не помню как зовут, а вот хэшей и многомерных массивов положить не успели

J>Спасибо, что есть уже то, что есть, а то могли бы еще лет 10 без стандарта сидеть, за обещание, что через 10 лет у нас будет стандарт, в котором будут и хеши, и интрузивные контейнеры, и встроенная лисп-машина.
Да просто отцы таки роднЫе!

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

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

J>>уже попал.
E>Ещё не уже попал
J>>А тогда они просто не успевали.
E>Ну вполне повод для претензий, что надобаляли всяких "меганужных" в стандарте next_permutation, vector<bool> и вектор значений, который я не помню как зовут, а вот хэшей и многомерных массивов положить не успели

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

J>>Спасибо, что есть уже то, что есть, а то могли бы еще лет 10 без стандарта сидеть, за обещание, что через 10 лет у нас будет стандарт, в котором будут и хеши, и интрузивные контейнеры, и встроенная лисп-машина.
E>Да просто отцы таки роднЫе!

Ну так потому что всем нужно свое (причем в каждый момент времени — разное), и у каждого есть повод для обиды, что вот именно то, что нужно ему, положить и не успели.

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

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

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

J>>>Спасибо, что есть уже то, что есть, а то могли бы еще лет 10 без стандарта сидеть, за обещание, что через 10 лет у нас будет стандарт, в котором будут и хеши, и интрузивные контейнеры, и встроенная лисп-машина.
E>>Да просто отцы таки роднЫе!

J>Ну так потому что всем нужно свое (причем в каждый момент времени — разное), и у каждого есть повод для обиды, что вот именно то, что нужно ему, положить и не успели.

Ну то есть ты не согласен с тем, что надо было не vector<bool> делать, а на hash_map усилия направить?

Erop пишет:

> S>А че за наезды на Степанова не по делу — hash_map чем-то не устраивает
> S>что ли?
> Да не устраивает. Тем, что в станадарт не попал...

Так это не к Степанову претензии, в его реализции STL вроде как сразу
hash_map был.

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

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

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

J>>>уже попал.
E>>Ещё не уже попал
J>>>А тогда они просто не успевали.
E>>Ну вполне повод для претензий, что надобаляли всяких "меганужных" в стандарте next_permutation, vector<bool> и вектор значений, который я не помню как зовут, а вот хэшей и многомерных массивов положить не успели

J>Вообще-то этот самый "вектор значений, который я не помню как зовут" и есть многомерный массив, причем в лучших традициях скоростных библиотек этих самых массивов.
примечательно как valarray выпадает из общего стиля stl. если взять например string или vector:

template <class сhar_type, class unusefull_stuff, class additional_butthurt> class basic_string;
template <class elem_type, class unusefull_stuff> class vector;

в valarray почему-то нет ни аллокатора ни стандартного набора begin/end .
чесно говоря я так и не понял для чего нужен этот класс, прочитав что это "многомерный массив" как-то пытался его использовать как двумерный массив, но так и не понял как в нем обратится к элементу по индексу [i,j].

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

Так, на чем мы тут остановились...

E>То есть, ты хочешь ссказать, что такой код

char buffer[sizeof( T )];
E>delete new( buffer )T;

не валиден?

Почему не валиден? Откуда это следует?

E>>>Можешь привести примеры реализаций, где будут такого рода проблемы? Или хотя бы идеи таких платформ и реализаций?
J>>Представь, что у тебя все объекты складываются компилятором куда-то в одному ему ведомое место (c целью последующей сборки мусора, например), а пользователю отдаются только типизированные хэндлы, все размером с long, независимо от того, сколько там данных в каждом объекте, ну и хранятся обратные указатели на все имеющиеся хэндлы.
J>>Так что если ты хэндл физически переместишь, таблица обратных указателей станет невалидной (она апдейтится при вызове конструкторов/деструкторов).
E>Боюсь, что такая реализация не будет соответсвовать стандарту. По крайней мере будут большие проблемы с адресной арефметикой и с возможностью прекращать существование объета, путём разрушения или переиспользования хранилища. Да и вообще с самим по себе понятием storage для объекта этот подход не совсем совместим, IMHO. С new размещения, с массивами. С моделью памяти, опять же, будут проблемы, IMHO.
Тут я никаких проблем не вижу. Адресная арифметика никуда не делась, просто она будет ходить по указателям на хэндлы.
Она все равно определена только для массивов, так что внутри объектов ее юзать некооректно.
Со storage вообще проблем не вижу.

E>Скажем как ты будешь обрабатывать ситуацию, при которой ты создаёшь объект по new размещениея, а памячть в твоём "теневом хранилоище объектов" закончилась?
Останавливать программу. Других вариантов стандарт не дает, из-за 18.4.1.3/1-3.
Если б позволяли — кинул бы bad::alloc.

E>Кроме того такой подход, скорее всего ещё и не целесообразен. Для POD это всё вообще не годится, так как про размещение POD в памяти всё описано явно. Так что в реализации С++ по любому прийдётся иметь традиционную реализацию размещения объектов в памяти. А тогда и не понятно зачем бы тогда отдельный огород городить с не POD типами...

Для подов он не просто не годится, он прямо запрещен.
Насчет огорода — это дело такое, ни ты, ни я не можем предсказать, кому когда что понадобится.
Как ты, так и я — мы занимаемся спекуляциями.
Другое дело, если бы у меня была именно такая "выстраданная" реализация — тогда бы я мог ее аргументированно защищать.
А так — ну вот есть в Стандарте такое ограничение, и все тут.
Если следуешь ему — твоя программа гарантированно (Стандартом) будет работать на любой мыслимой стандартной реализации С++.
Если нет — нет.

E>>>В частности, насколько я понимаю стандарт гарантирует, что объект, созданный по new будет размещён начиная с адреса, который вернт operator new и будет занимать не более sizeof байт...
J>>да, вопрос только в том, как понимать "размещен по адресу". Я это понимаю как "этот адрес можно разыменовать и обращаться к членам".
E>Нет, любой указатель можно привести к const char* и получить доступ к бинарному представлению данных...
ссылку на стандарт дашь?

J>>см. выше пример с хэндлами. Все в рамках семантики.
E>Не годится пример с хэндлами. Он не будет соответсвовать стандарту во многих местах. Да и с многими программами будет несовместим, очевидно. Кроме того, AFAIK, таких реализаций интерпретаторов С++ нет. Что, IMHO, и не удивительно...

E>>>Или это таки в комитете перебдели?
J>>В комитете, вообще-то, как раз разработчики компиляторов и сидят
E>Ну перебдеть-то это не мешает? С невозможностью двигать содержимое std::vector по памяти перебдели же?
еще раз — на каких условиях ее реализовывать?
По умолчанию это можно делать только для подов, но и с подами беда — вот у меня прямо сейчас есть структуры с указателями внутрь, хоть и поды. Если их передвинуть — все слетит нафиг.
Стало быть, надо отдельный механизм предусматривать, правильно? А, во-первых, продумать, как это правильно сделать (вариантов куча, и с наскоку не видно, какой лучше), чтоб все удобно было — на это время нужно, а во-вторых, это оптимизация, а для начала надо предоставить базовую функциональность, что и было сделано.

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

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


K>чесно говоря я так и не понял для чего нужен этот класс, прочитав что это "многомерный массив" как-то пытался его использовать как двумерный массив, но так и не понял как в нем обратится к элементу по индексу [i,j].

через слайсы, или как они там называются.
Если ты знаком с BLAS, то не должно быть проблем (я не знаком и с многомерными массивами по долгу службы не общаюсь).

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

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

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

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

Чем плохой? Ты им пользовался? (Я — нет.)
Неудобный — возможно, но он следует традициям лучших на то время библиотек линейной алгебры (фортрановских, в основном), так что для профессионалов в оных он должен быть удобен (я так предполагаю).

J>>>>Спасибо, что есть уже то, что есть, а то могли бы еще лет 10 без стандарта сидеть, за обещание, что через 10 лет у нас будет стандарт, в котором будут и хеши, и интрузивные контейнеры, и встроенная лисп-машина.
E>>>Да просто отцы таки роднЫе!

J>>Ну так потому что всем нужно свое (причем в каждый момент времени — разное), и у каждого есть повод для обиды, что вот именно то, что нужно ему, положить и не успели.

E>Ну то есть ты не согласен с тем, что надо было не vector<bool> делать, а на hash_map усилия направить?

Чтоб сделать vector<bool>, нужен час времени, а вот чтоб сделать хеш — тут надо думать очень много, потому что очень много вопросов возникает и придется очень много решений принимать.

А уж если ты меня спрашиваешь... Да, не согласен.
На мой взгляд, там в языке самом достаточно проблем, чтоб забить и на hash_map и все остальное (потому что все это доступно в других библиотеках и так), но зато сделать то, что нельзя сделать без поддержки со стороны языка (ту же паралаллельность, рефлексию, метапрограммирование, лямбды, замыкания, модули, динамические библиотеки и прочее). А хеш мне точно не уперся — реализаций достаточно, выбирай любую. Будет время — ОК, можно и вставить. Но после того, как сделано то, что действительно важно и не сделать иначе.

Имхо, в стандарте вообще достаточно было только зафиксировать, что в контейнерах должны быть объявлены определенные типы (типа value_type и iterator) и определенные методы (типа size и begin/end), а всем остальным вообще не заморачиваться, пока не решены остальные проблемы. Но раз уж предоставили референсные реализации вектора/сета/мапа — спасибо, остальное сами напишем. Кто ж виноват, что люди с какого-то бодуна решили, что эти несчастные три контейнера и 15 алгоритмов — это и все, что есть и будет, а все остальное — ни-ни, и вместо того, чтобы писать собственные контейнеры и алгоритмы, удовлетворяющие базовым требованиям по интерфейсу, извращаются через стандартные и потом матерятся на всех углах...

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

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

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

E>>То есть, ты хочешь ссказать, что такой код

char buffer[sizeof( T )];
E>>delete new( buffer )T;

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

E>>Боюсь, что такая реализация не будет соответсвовать стандарту. По крайней мере будут большие проблемы с адресной арефметикой и с возможностью прекращать существование объета, путём разрушения или переиспользования хранилища. Да и вообще с самим по себе понятием storage для объекта этот подход не совсем совместим, IMHO. С new размещения, с массивами. С моделью памяти, опять же, будут проблемы, IMHO.
J>Тут я никаких проблем не вижу. Адресная арифметика никуда не делась, просто она будет ходить по указателям на хэндлы.
J>Она все равно определена только для массивов, так что внутри объектов ее юзать некооректно.
А если приватное поле -- массив?
J>Со storage вообще проблем не вижу.
Проблема в том, что storage -- это память, занимаемая объектом. НИкакого "теневого storage" вроде как не предусмотрено

E>>Скажем как ты будешь обрабатывать ситуацию, при которой ты создаёшь объект по new размещениея, а памячть в твоём "теневом хранилоище объектов" закончилась?
J>Останавливать программу. Других вариантов стандарт не дает, из-за 18.4.1.3/1-3.
А разве останавливать можно?
J>Если б позволяли — кинул бы bad::alloc.
Мне кажется, что new размещениея не может не работать...

J>Насчет огорода — это дело такое, ни ты, ни я не можем предсказать, кому когда что понадобится.
J>Как ты, так и я — мы занимаемся спекуляциями.
Ну я поэтому и написал "скорее всего"
J>Другое дело, если бы у меня была именно такая "выстраданная" реализация — тогда бы я мог ее аргументированно защищать.
J>А так — ну вот есть в Стандарте такое ограничение, и все тут.
Интересно бы понять чем оно вызвано. Я всё ещё думаю, что это баг.

E>>Нет, любой указатель можно привести к const char* и получить доступ к бинарному представлению данных...
J>ссылку на стандарт дашь?
КОгда встречусь с текстом -- дам. Но, кроме описания того, к чему можно приводить указатели, стандарт ещё сожержит подробное очень описание работы перекрытых operator new/delete. И там очень активно используется идея занимаемой объектом памяти. Так что твоя реализация, IMHO, не пролезет

E>>Ну перебдеть-то это не мешает? С невозможностью двигать содержимое std::vector по памяти перебдели же?
J>еще раз — на каких условиях ее реализовывать?
J>По умолчанию это можно делать только для подов, но и с подами беда — вот у меня прямо сейчас есть структуры с указателями внутрь, хоть и поды. Если их передвинуть — все слетит нафиг.
Ну я тоже согласен, что возможность двигать объекты по памяти никак не связана с их POD'овостью...

J>Стало быть, надо отдельный механизм предусматривать, правильно? А, во-первых, продумать, как это правильно сделать (вариантов куча, и с наскоку не видно, какой лучше), чтоб все удобно было — на это время нужно, а во-вторых, это оптимизация, а для начала надо предоставить базовую функциональность, что и было сделано.
Без этого std:vector малоюзабелен .
Интересно было бы понимать зачем вообще было выбрано требование на элемент контейнера иметь семантику значения. Необъодимым оно не является, необременительным тоже...
Вообще в дизайне STL лично мне очень не нравится отсутсвие целенаправленности. Скажем вот добавили в контейнеры аллокаторы. При этом зачем это сделали не понятно. Ни возмоэность передать контейнеру конкретный пул памяти не предусмотрели, ни возможность гранулировать аллокации. Результат печальный -- аллокаторы есть, а толку нет. И так во многих очень местах

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

J>Чем плохой? Ты им пользовался? (Я — нет.)
J>Неудобный — возможно, но он следует традициям лучших на то время библиотек линейной алгебры (фортрановских, в основном), так что для профессионалов в оных он должен быть удобен (я так предполагаю).
Ну вот я из FORTRAN пришёл к С++, а валуеареем так воспользоваться и не пришлось... В FORTRAN есть очень хорошие библиотеки линейной алгебры. Но хороши они не контейнерами, а алгеброй. При этом в языке есть некоторые трудности с работой с памятью, так что тащить массивы оттуда в С++ -- идея так себе...

J>Чтоб сделать vector<bool>, нужен час времени, а вот чтоб сделать хеш — тут надо думать очень много, потому что очень много вопросов возникает и придется очень много решений принимать.
Насколько я понимаю, комитет работает коллегиально. Так что затраты бюрократических усилий сравнимы. Да и сам текст стандарта родить тоже непросто.

J>На мой взгляд, там в языке самом достаточно проблем, чтоб забить и на hash_map и все остальное (потому что все это доступно в других библиотеках и так), но зато сделать то, что нельзя сделать без поддержки со стороны языка (ту же паралаллельность, рефлексию, метапрограммирование, лямбды, замыкания, модули, динамические библиотеки и прочее). А хеш мне точно не уперся — реализаций достаточно, выбирай любую. Будет время — ОК, можно и вставить. Но после того, как сделано то, что действительно важно и не сделать иначе.
Насколько я понимаю, всех этих запросов не было на момент создания языка. Когда принимали стандарт и STL, уже могли бы заняться чем-то полезным, а не замораживанием степановского поделия навека. Но, видимо, зоопарк библиотек достал больше, чем отсутствие рефлексии.
Только они STL не особо хороший приняли, так что как у всех библиотек были свои контейнеры, так и остались
Так что главную задачу они не выполнили

J>Имхо, в стандарте вообще достаточно было только зафиксировать, что в контейнерах должны быть объявлены определенные типы (типа value_type и iterator) и определенные методы (типа size и begin/end), а всем остальным вообще не заморачиваться, пока не решены остальные проблемы. Но раз уж предоставили референсные реализации вектора/сета/мапа — спасибо, остальное сами напишем. Кто ж виноват, что люди с какого-то бодуна решили, что эти несчастные три контейнера и 15 алгоритмов — это и все, что есть и будет, а все остальное — ни-ни, и вместо того, чтобы писать собственные контейнеры и алгоритмы, удовлетворяющие базовым требованиям по интерфейсу, извращаются через стандартные и потом матерятся на всех углах...
Не понятно на кой вообще связываться с этим набором сэмплов по программированию шаблонов функций, работающих поверх итераторов...

J>Хорошо, что есть вменяемые конторы типа адоба, которые это делают централизованно и выкладывают в общий доступ, и буст, который занимается тем же, только бесплатно.
+1
Хорошо, что кто-то пытается всё это развивать, но, IMHO, значительная часть буста развивается не совсем туда, а STL скорее препятствует развитию, а не способствует
Нормальные шаблоны (с рефлексией, там скажем, и всякими аттрибутами типов) добавить в С++ коммитет не затянул и в этот раз, кстати... Либо я не в курсе.
Скажем можно ли теперь будет проитерировать поля объекта-параметра шаблона? Или можно ли будет написать шаблон для всех конструкторов типа? Или ещё что-нибудь в таком роде?