Получать и устанавливать тип от FunctionMap можно и по индексу....
Т.е нужен такой хитрый compile-runtime полиморфизм.
Можно конечно сделать функторы draw_* и rotate_* унаследованные от абстрактного класа и сделать виртуальный метод, а потом в main
создавать их через new. Но мне так не нравится.
Вопрос 1: Такое вобще реализуемо на C++ ?
Вопрос 2: Может ли тут помочь boost::mpl и как?
Здравствуйте, Vinick, Вы писали:
V>Получать и устанавливать тип от FunctionMap можно и по индексу.... V>Т.е нужен такой хитрый compile-runtime полиморфизм.
Где же это compile-time, когда самый что ни на есть run-time.
Такой полиморфизм можно сделать или через виртуальные методы, или через указатели на функции (или, более общо, boost::function).
Но здесь таится другая засада. Тебе нужен не просто полиморфизм, но мультиметоды. Ведь, как я понимаю, FunctorMap должна реализовать шаблон оператора, применяющий все эти полиморфные действия к произвольному типу.
Если бы тип аргумента (Circle) был известен заранее, до конструирования FunctorMap, — то проблем нет.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Vinick, Вы писали:
V>>Получать и устанавливать тип от FunctionMap можно и по индексу.... V>>Т.е нужен такой хитрый compile-runtime полиморфизм.
К>Где же это compile-time, когда самый что ни на есть run-time.
Вобще-то я надеялся, что будет работать что-то типа такого
struct A {
void f() { std::cout << "A()" << std::endl; }
};
struct B {
void f() { std::cout << "B()" << std::endl; }
};
int main()
{
using namespace boost;
typedef mpl::map<mpl::pair<mpl::int_<0>,void> > map;
int i=1;
if( i ==1 )
{
typedef mpl::insert<map,mpl::pair <mpl::int_<1>, A> >::type map1;
}
else
typedef mpl::insert<map,mpl::pair <mpl::int_<1>,B> >::type map1;
typedef mpl::at<map1,mpl::int_<1> >::type S;
S s;
s.f();
return 0;
}
Но судя по всему такое невозможно.
К>Если бы тип аргумента (Circle) был известен заранее, до конструирования FunctorMap, — то проблем нет. К>
Естественно: типы должны определяться во время компиляции. Да и область видимости обоих типов map1 ограничена ветками then и else, а за пределами if ни один из них недоступен.
class part_visitor :
public _visitor<part_visitor>
{};
class spell_checker :
public part_visitor::visitor<spell_checker>
{
public:
wchar_t * h_mem;
// другие св-ва
};
class part :
virtual public part_visitor::_is_visitable
{
protected:
virtual ~part() = 0;
};
class some_part1 :
public part_visitor::is_visitable<some_part1>
{};
template <>
template <>
template <>
void spell_checker::action<some_part1>::do_action(T & target)
{
// конкретная реализация действия
}
void test()
{
part_visitor * hv= new spell_checker(/*параметры*/);
part * hp= new some_part1;
hp->visit(hv);
// удаление hv, hp не забыть!
}
Имена, начинающиеся со знака '_' (с подчёркивания)
это имена интерфейсов.
Vinick wrote:
> Не знаю даже как объяснить по человечески чего я хочу... > Хочу сделать как нибудь так.
[]
> Получать и устанавливать тип от FunctionMap можно и по индексу.... > Т.е нужен такой хитрый compile-runtime полиморфизм. > > Можно конечно сделать функторы draw_* и rotate_* унаследованные от > абстрактного класа и сделать виртуальный метод, а потом в main > создавать их через new. Но мне так не нравится.
Spirit is implemented using expression templates. This is a very powerful
technique. Along with its power comes some complications. We almost take for
granted that when we write i | j >> k where i, j and k are all integers the
result is still an integer. Yet, with expression templates, the same expression
i | j >> k where i, j and k are of type T, the result is a complex composite
type [see Basic Concepts]. Spirit expressions, which are combinations of
primitives and composites yield an infinite set of new types. One problem is
that C++ offers no easy facility to deduce the type of an arbitrarily complex
expression that yields a complex type.
...
rule<> r = i | j >> k; // where i, j, and k are chlit<> objects
It might not be apparent but behind the scenes, plain rules are actually
implemented using a pointer to a runtime polymorphic abstract class that holds
the dynamic type of the parser assigned to it. When a Spirit expression is
assigned to a rule, its type is encapsulated in a concrete subclass of the
abstract class. A virtual parse function delegates the parsing to the
encapsulated object.
-- Maxim Yegorushkin
No Microsoft product was used in any way to write or send this text.
If you use a Microsoft product to read it, you're doing so at your own risk
Здравствуйте, Vinick, Вы писали:
V>Здравствуйте, Кодт, Вы писали:
К>>Здравствуйте, Vinick, Вы писали:
V>>>Получать и устанавливать тип от FunctionMap можно и по индексу.... V>>>Т.е нужен такой хитрый compile-runtime полиморфизм.
К>>Где же это compile-time, когда самый что ни на есть run-time.
V>Вобще-то я надеялся, что будет работать что-то типа такого V>
Перекуём баги на фичи!
