Метод pack()

В классах list, set, array, etc. есть метод container pack(), который должен конвертировать содержимое соответствующего контейнерного класса в "стандартный" контейнер Х++.
В процессе его тестирования были обнаружены следующие особенности:

• количество элементов в исходном классе на 3 меньше длины получаемого контейнера, то есть Source.elements() возвращает N, а conlen(Dest) - N + 3;
• первый элемент получаемого контейнера всегда (по крайней мере в моих экспериментах) равен 1;
• второй и третий элементы - соответственно 1 и N;
• сами данные начинаются с 4-го элемента.

Кто-то может объяснить предназначение этих трех элементов итогового контейнера? Правильно ли я уловил закономерность?

[mazzy]

Best Practice: Pack-unpack pattern
http://technet.navision.com/usered/BPH/Dev.../PackUnpack.htm

Паттерн применяется для того, чтобы упаковать в один объект несколько небольших переменных. Контейнер передается между клиентом и AOS.

По соглашению, первый элемент контейнера - номер версии алгоритма упаковки-распаковки. Далее идут переменные, которые обрабатываются unpack'ом.

Насколько я понимаю, классы list, set, array хранят что-то свое в дополнительных параметрах. Что конкретно - не знаю.

А зачем? Если хочется сделать свой класс, то надо унаследовать от стандартного. Затем в pack|unpack вызывать super. А в своем классе заниматься только спецификой.

Цитата:

Сообщение от mazzy

А зачем? Если хочется сделать свой класс, то надо унаследовать от стандартного. Затем в pack|unpack вызывать super. А в своем классе заниматься только спецификой.

Дело не в наследовании. Задача была более тривиальная. Был экземпляр класса list, содержащий большое количество элементов, но не "несколько небольших переменных". Поиск нужного элемента в списке при помощи listIterator производится гораздо дольше, чем в контейнере (confind()), несмотря на уверения в документации по поводу ориентированности на быстродействие:

Цитата:

The implementation of lists is such that traversal of the list elements is very fast.

Так вот, я попробовал переделать список в контейнер, и там уже искать. Но из-за этих трех первых элементов очень долго ломал голову .
Зато скорость, все-таки увеличил!

[mazzy]

confind() ищет быстро и корректно, если внутри контейнера атомарные значения

list - не ускоряет поиск. Он быстро делает перебор значений.
Для поиска лучше воспрользоваться map'ом.

Согласен, map гораздо лучше! Пришел к этому сегодня утром Но чтобы убедиться, хотелось попробовать ВСЕ! Истина, как известно, познается в сравнении - вот я и моделировал всяческие надуманные поиски/переборы с целью протестировать как можно большее кол-во способов (пусть даже заведомо для этого не предназначенных).
Кстати, "атомарные" значения - это значит одного типа?

[Андре_imported]

Цитата:

Для поиска лучше воспрользоваться map'ом.

Согласен. Работает гораздо быстрее. Недаром закрытие склада переделали так, что оно стало работать с мапами.

[dirigente]

Цитата:

Сообщение от Ruff

Кстати, "атомарные" значения - это значит одного типа?

Насколько я понимаю "атомарные" = "неделимые" или "простые".

Цитата:

Насколько я понимаю "атомарные" = "неделимые" или "простые".

Спасибо, я уже догадался.

Кстати, видел где-то на technet-е - там кто-то пытался в set контейнеры запихать! Так от этого дела Аксапта аж падает - сам проверял.