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

наверное, запутал. поясню

к примеру, если вектор может хранить указатели на интерфейс и работать с элементами (реализации интерфейса) с помощью динамическорго полиморфизма:


то "статический" контейнер хранит шаблоны и работает с конкретизациями шаблона (на этапе компиляции, конечно)


ну и сами вопросы - как это называется, есть ли такое в бусте (сам бы поискал, если б знал, что искать), и если нет, то где есть?

Если честно, я не понял, что ты хочешь. И, главное, зачем. Может тебе нужен boost::tuple?
Я под статическим контейнером понимаю, например, тот же vector, элементы которого задаются на этапе компиляции (проще говоря, обычный статический массив с интерфейсом от, например, std::vector).

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

если у меня есть ровно 3 однородных (то есть имеющих одинаковую функциональность) элемента, то, для их "одинаковой" обработки хотелось бы поместить их в контейнер и работать со всем контейнером.
Можно, конечно, их унаследовать от одного интерфейса и запихнуть в вектор, но при этом будет некоторое замедление работы из-за вызова функций через таблицу вирт. функций.
Но зачем мне это нужно, если я точно знаю, что сейчас , к примеру,  для 1го элемента контейнера мне нужно вызвать "оту" функцию, а для второго - "именно оту"?
потому и хочу тут прикрутить не динамический полиморфизм, а статический. И потому хотелось бы контейнер, который будет не на этапе работы программы смотреть, какую же ему функцию вызвать, а подставлять ее вызов уже на этапе компиляции.

У тебя старый микроконтроллер? Профайлер показал, что самое слабое место программы это вызов виртуальных методов?

Здается мне, что у тебя что-то не то с дизайном. Разнородные сущности в одном контейнере - это настораживает.

как уже сказали boost::tuple. Но по большому счету это бред.

допустим


хм...



boost::tuple насколько я понял, содержит как раз абсолютно разнородные сущности
хотя можно его и специализировать, возможно... за подсказку спасибо обоим

насчет бреда - в конце таких фраз нужно добавлять что-то типа "имхо".

Добавлено @ 13:53
в общем, я спрашивал, знает ли кто-то о таком, а не просил рассказать мне, что нет ситуаций, когда это может пригодиться...
ситуацию я привести могу, так как с ней столкнулся, но на объяснение ее уйдет много букв 

Это сообщение отредактировал(а) Alek86 - 12.1.2008, 13:55

заповедь первая - не оптимизируй!)))
На этапе компиляции никакие ф-ии не вызываются, можно только константы и типы вычислять. Можно на этапе компиляции создавать списки типов, векторы типов, и тд.. смотри boost::mpl.
там можно написать так:

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

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

я про вызов и не говорил, а про подстановку


  вот его и хотелось использовать
похоже, это можно сделать с помощью mpl::for_each