имеет ли смысл реализовывать следующее...

[bebabo]

представьте  игру -  несколько уровней, на которых персонаж, управляемый игроком, выполняет следующие действия:
1) при нажатии влево-вправо -  ходит туда-сюда
2) при нажатии Z - выполняет основное действие (например стреляет)
3) при нажатии X - выполняет дополнительное действие (например бросает гранату).
на всех уровнях количество действий постоянно, но если первый пункт будет на всех уровнях одинаков, то основное и дополнительное действия будут на каждом уровне различными.

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

другой вариант, до которого я додумался -
создаем базовый класс, в котором нет ничего кроме виртуальной функции action, где, в свою очередь, реализовано действие "ходьба". от этого класса наследуем классы - основное и дополнительное действие - в которых перегружаем функцию action - прописываем  в нем нужные нам действия. и таких наследников создаем по количеству уровней. т.е. если уровня три, получаем
1) базовый класс ходьба
2) наследник базового - основное движение уровня 1
3) наследник базового - доп. движение уровня 1
4) наследник базового - основное движение уровня 2
5) наследник базового - доп. движение уровня 2
6) наследник базового - основное движение уровня 3
7) наследник базового - доп. движение уровня 3
уф! создали ) теперь создаем вектор указателей на базовый класс. в векторе будет три объекта. на позиции 0 - объект базового класса, на поз. 1 - основное движение уровня 1, на поз. 2 - доп. движение уровня 1. при нажатии игроком на кнопку итератор этого вектора будет устанавливаться на нужное действие и выполняться в коде будет только один объект-функция.
например: игрок выбирает стрельбу - нажимает Z, итератор устанавливается в 1, и выполняется стрельба. хочу выполнить дополнительное действие - изменяется итератор, указывая теперь на дополнительное действие.
при переходе на новый уровень - объекты на позиции 1 и 2 заменяются.

как вы думаете - этот вариант извращение или в этом действительно есть смысл? т.е. насколько этот подход целесобразнее первого - будет ли поиск в таблице виртуальных функций быстрее, чем switch в первом варианте?

[Алексей++]

свич быстрее, палюбасу.  И менее запутанная логика.

а  то, что много кода в case - так это решается дополнительными функциями или, на крайний случай, выносом кода в xxx.h и

Код:

case 2:
{
   #unclude "xxx.h"
}
break;

читабельность сохраняется )

[nikedeforest]

А я поддержу так называемый "другой вариант". СМысл в этом есть и полне нормальный.

[Алексей++]

nikedeforest, не спорю, я своё мнение высказал.  Только во том варианте куча-куча классов намечается...

[nikedeforest]

ВСе быть может. Но ООП создано все же для облегчения проектирования. Давай посмотрим с другой стороны. ЗАхочет программмер добавить еще одно основное движение, к примеру, прыжок. В случае ООП мы вносим изменения в базовый класс, которые потом наследуются. Одного изменения достаточно. А вот сколько изменений придется добавиться в switch? И еще бы не забыть ничего . А если мы решим добавить что-то на том уровне, что-то на другом, не обалдеем ли мы бегать по этим кейсам и не забудим ли мы чего? Вто такая мысль.

[Алексей++]

а вот тут требуется уточнение от автора ) , что он хочет -

1 вариант  -
  1 лвл = движение A  (скажем, прыжок)
  2 лвл = движение A-B (прыжок, с одновременным показыванием языка)
  3 лвл = движение A-B-C (прыжок, с одновременным показыванием языка и вращением вокруг продольной оси тела)

2 вариант  -
  1 лвл = движение A  (некий прыжок)
  2 лвл = движение B ( другой прыжок)
  3 лвл = движение C ( сапсем другой прыжок)


в 1м вариате классы (то есть движение постоянно дополняется) , во втором - свич

[bebabo]

...в 1м вариате классы (то есть движение постоянно дополняется) , во втором - свич

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

[bebabo]

nikedeforest, душой я тоже за второй вариант) он кажется мне красивее) а если учесть, что в каждом действии еще возможны вложенные свичи или if-else - контролирующие данное действие - то, мне кажется, что и по скорости второй вариант может выиграть по сравнению с первым.

[Алексей++]

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

нифига не медленная, нормальная )  . Нет там никакого поиска вообще то...

Но свич нужен будет уже для сотни классов, а не действий.

bebabo, если действия продолженные, то лучше классы. Уже решили ведь )

[bebabo]

свич в процессе самой игры не понадобится. разве только в моменты перехода с одного уровня на другой, когда нужно будет поменять объекты-функции в векторе. а в процессе самой игры - будет изменяться значение итератора в зависимости от нажатой клавиши: либо 0, либо 1, либо 2, и исполняться один единственный объект-функция.

[v2]

Массив функций ..

[bebabo]

Массив функций ..

это поправка к "исполняться один единственный объект-функция" ? нет, именно одна функция. та, на которую будет указывать итератор

[bebabo]

нашел еще один способ реализовать подобную ситстему - использовать вместо виртуальных функций boost::function.
только вот как-то странно - при попытке откомпилировать пример использования boost::function, компилятор ругается, что мол никакой function в boost нет.