А в этом случае не придется для каждого типа добавлять новый оператор в IVisitor? Если да, то не подходит.

Это сообщение отредактировал(а) tilin - 27.10.2009, 23:25

если они однотипные, то их можно сгенирировать с помощью шаблона

если ты будешь использовать variant, то у тебя в коде будет что-то вроде - 


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

Типы могут быть любые. Вариант у меня выглядит вот так:



В классе есть 

В коде значение получается например так: 

и как-же ты с ними работаешь потом, если не секрет?

Вопрос не совсем понял, но например в варианте с int так:

во первых, здесь нужно явное приведение типа (static_cast), во вторых, если в v[0] не int - оператор приведения типа бросит исключение, мне интересно, что ты будешь делать, если у тебя в одном контейнере значения разных типов, как в твоем первом примере?

Вот пример - код рабочий.

и бесполезный  

приходи, когда попробуешь написать реальный код, использующий этот класс, вопросы сразу возникнут, я гарантирую это  

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

пока ты знаешь тип возвращаемого значения
просто у тебя нет способа узнать тип значение, хранящегося в Variant-e, я уже несколько постов пытаюсь на это намекнуть  

вообще, лень вникать, sry
просто, если у тебя не возникает необходимости определять тип значения, хранящегося в Variant-е, значит вероятно, тебе вообще не нужен Variant, ты просто усложнил архитектуру приложения  

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

  

если тип объекта известен и помощь компилятора не требуется, то хранить объект можно и как void *


как раз от такого как происходит взаимодействие с элементом контейнера и зависит какой интерфейс должен поддерживать объект.


как я понимаю у Вас тип зависит от индекса, тогда

  если контейнер условно находится в библиотеке которая ничего не знает о типах, и предоставляет просто место для хранения, то тут как раз хранение по void* и каждый клиент имеет интерфейс по получению "готовых" объектов. 

  если же нужно хранить разношерстные элементы как одну структуру и все типы статически известные, то посмотрите например библиотечку boost::fusion в частности :
http://www.boost.org/doc/libs/1_40_0/libs/...ner/vector.html

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

Абсолютно не зависит. Объекты в массив добавляются в произвольной последовательности.



В первом варианте Get() возвращал именно void*, потом клиент делал static_cast до нужного типа. Но мне хотелось, чтобы вместо 
было

Конечно использовать динамическое приведение типов вместо статического не есть Гут. И я еще подумаю, какой из них выбрать.

так тип объекта с чем то связан или программист сам должен помнить под какой индекс что он добавил ?!


имхо, приведенной в этом топике информации недостаточно для совета.

Общая задача выглядит так:

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