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

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

P>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

В смысле, что бы искалось по key, а [begin, end) были в порядке добавления?
Тогда без доп. вектора (или другого контейнера) нельзя.

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

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

P>>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

S>В смысле, что бы искалось по key, а [begin, end) были в порядке добавления?
S>Тогда без доп. вектора (или другого контейнера) нельзя.

Что ж, печально. В Java есть HashSet — там и значения упорядочены в порядке добавления, и доступ по ключу. Уже в который раз убеждаюсь, что по сравнению с Java, библиотеки С++ позволяют не такие функциональные и удобные.

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

S>>В смысле, что бы искалось по key, а [begin, end) были в порядке добавления?
S>>Тогда без доп. вектора (или другого контейнера) нельзя.

P>Что ж, печально. В Java есть HashSet — там и значения упорядочены в порядке добавления, и доступ по ключу. Уже в который раз убеждаюсь, что по сравнению с Java, библиотеки С++ позволяют не такие функциональные и удобные.

В стандарте С++ нет hash_set, но большинство реализаций STL реализует ее в виде расширения.

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

S>В стандарте С++ нет hash_set, но большинство реализаций STL реализует ее в виде расширения.

В MS-ском тоже имеется hash_set. Надеюсь, разрабы разных портов стл смотрят друг на друга, чтобы обеспечить одинаковые интерфейсы. Не хотелось бы иметь не переносимы код (пусть и на уровне библиотеки)

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

S>В стандарте С++ нет hash_set, но большинство реализаций STL реализует ее в виде расширения.
Правда я не уверен, что итераторы данного hash_set итерируют в порядке добаления %(.

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

P>В MS-ском тоже имеется hash_set. Надеюсь, разрабы разных портов стл смотрят друг на друга, чтобы обеспечить одинаковые интерфейсы. Не хотелось бы иметь не переносимы код (пусть и на уровне библиотеки)

Я проверил hash_set из MS VS 7.1. Элеменды итерируются не в порядке добавления.
+ к тому он объявлен deprecated.
Так, что придется либо писать велосипед, либо искать библиотеку. %(
Можно посмотреть здесь

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

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

P>>В MS-ском тоже имеется hash_set. Надеюсь, разрабы разных портов стл смотрят друг на друга, чтобы обеспечить одинаковые интерфейсы. Не хотелось бы иметь не переносимы код (пусть и на уровне библиотеки)

S>Я проверил hash_set из MS VS 7.1. Элеменды итерируются не в порядке добавления.
S>+ к тому он объявлен deprecated.
S>Так, что придется либо писать велосипед, либо искать библиотеку. %(
S>Можно посмотреть здесь

Велосипед писать не буду, просто тупо прикручу костыль к имеющемуся мапу — отнаследуюсь, заведу вектор и буду туды складывать ссылки на добавляемые объекты. Впрочем, за ссылку спасибо, может что и найдется.

P>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

boost::multy_index должен помочь, насколько я понимаю.

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

P>Велосипед писать не буду, просто тупо прикручу костыль к имеющемуся мапу — отнаследуюсь, заведу вектор и буду туды складывать ссылки на добавляемые объекты. Впрочем, за ссылку спасибо, может что и найдется.
ИМХО, наследоваться не лучший метод. Лучше агрегировать.

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

P>>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

L>boost::multy_index должен помочь, насколько я понимаю.

ОК, будем смотреть в его сторону.

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

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

P>>Велосипед писать не буду, просто тупо прикручу костыль к имеющемуся мапу — отнаследуюсь, заведу вектор и буду туды складывать ссылки на добавляемые объекты. Впрочем, за ссылку спасибо, может что и найдется.
S>ИМХО, наследоваться не лучший метод. Лучше агрегировать.

Факт. Не придется лазить во внутренностях этого мапа, в котором без бутылки не разберешься .

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

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

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

P>>>Велосипед писать не буду, просто тупо прикручу костыль к имеющемуся мапу — отнаследуюсь, заведу вектор и буду туды складывать ссылки на добавляемые объекты. Впрочем, за ссылку спасибо, может что и найдется.
S>>ИМХО, наследоваться не лучший метод. Лучше агрегировать.

P>Факт. Не придется лазить во внутренностях этого мапа, в котором без бутылки не разберешься .

Дык лазить-то как раз не надо. Просто агрегируй его и пересылай нужные тебе запросы.
Параллельно по insert добавляй в вектор.
А то, оператор [] ты хрен отловишь %). Придется свою проксю писать. Или во внутренности лезть %).

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

P>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

А я чё-то не пойму... map — это дерево, т.е. в нём все элементы хранятся отсортированными (если проходить итератором). Т.е. они там принципиально не могут быть в порядке добавления...

Praetor wrote:

> S>В смысле, что бы искалось по key, а [begin, end) были в порядке
> добавления?
> S>Тогда без доп. вектора (или другого контейнера) нельзя.

> Что ж, печально. В Java есть HashSet — там и значения упорядочены в
> порядке добавления, и доступ по ключу. Уже в который раз убеждаюсь, что
Бред. Читаем jdk1.5.0_07/docs/api/java/util/HashSet.html#iterator()

Returns an iterator over the elements in this set. The elements are returned in no particular order.

Кстати, HashSet это не map. Но посмотрим и HashMap... хм... а он сам по себе не перебирается, есть только entrySet(),
смотрим jdk1.5.0_07/docs/api/java/util/Set.html#iterator(), там

Returns an iterator over the elements in this set. The elements are returned in no particular order (unless
this set is an instance of some class that provides a guarantee).

замечание в скобках, как я понимаю, только для TreeSet, что соотвествует std::set. Так что в этом вопросе библиотеки
предоставляют одну и ту же функциональность.

> по сравнению с Java, библиотеки С++ позволяют не такие функциональные и
> удобные.
Ну так и пишите на Java, а C++ не для вас.

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

P>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

Какова логика проекта? Если первичным является порядок времени занесения, то он должен быть в ключе. Если же есть другой ключ по которому надо вести поиск, причем здесь время занесения. Можно конечно поробовать использовать pair в качестве ключа, в которой будет время и ключ, и перегрузить оператор < для нее. Но зачем? Мапы обычно используются для пыстрого поиска, а так смысл ка-то теряется...

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

P>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

std::deque<std::pair<Key const, Value> >?

Интерфейс на 90% как у std::map. Даже итераторы совместимые

P>>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

RO>std::deque<std::pair<Key const, Value> >?

RO>Интерфейс на 90% как у std::map. Даже итераторы совместимые

А искать как? Последовательным перебором?

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

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

P>>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

RO>std::deque<std::pair<Key const, Value> >?

RO>Интерфейс на 90% как у std::map. Даже итераторы совместимые

Ну да совместимые, такое скажешь У deque — RandomAccessIterator, у map — BidirectionalIterator

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

P>>>Нужно обеспечить хранение данных в ассоциативном контейнере STL (map) в порядке добавления. Не хочется ради этого заводить дполнительный вектор.

RO>>std::deque<std::pair<Key const, Value> >?

RO>>Интерфейс на 90% как у std::map. Даже итераторы совместимые

L>А искать как? Последовательным перебором?

По индексу