Вызывает функцию передвижения прямоугольника, если это прямоугольник. Т.е. решает if-ом ту задачу, которую решают виртуальные функции.

В итоге выходит, что средствами C++ красивого решения придумать не получается (имеется ввиду встроенными средствами) и приходиться выкручиваться своей собственной таблицей.

mes

Спасибо. Поработаю немного над примером, посмотрим что получиться.
  

Всем спасибо за участие.


Это сообщение отредактировал(а) azesmcar - 14.11.2011, 14:01

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

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

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

Это сообщение отредактировал(а) azesmcar - 14.11.2011, 15:44

На данный момент я вижу вашу задачу так.. Есть лист на котоый могут быть положены объекты разных типов..
1. Объекты разделены по группам (фигуры, разделители, текст и т.д.)  при этом должна быть возможность динамечиски добавлять 
2. Лист предоставляет набор фиксированных действий предоставляемых над любыми объектами, и реализаторы сами решают какие команды поддерживают.. 
Это все что удалось с Вас вытянуть.. В таком изложении задача не очень большая, но внутрене чувствуются что это далеко не все..


мне кажется Вы упустили чего то.. 


так наоборот хорошо есть время пообсуждать..  (конечнонастаивать я не могу, просто тема заинтересовала )


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




Это сообщение отредактировал(а) mes - 14.11.2011, 16:21

В принципе да, но здесь есть одно но, добавлять могут разные люди. И те, у кого есть доступ к исходникам, и те, у кого их нет.
Т.е. Я могу добавить новый тип объектов, а может добавить программист из другой команды, который просто использует наш редактор как фреймворк для своего приложения.


Так она и не большая, большой ее делают количество операций с объектами, а задача сама небольшая, просто душа требует красивого решения  


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


да, если получиться приблизиться к компьютеру  
но я буду стараться.


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

такое отменяется (это я про visitor-а).
Остается либо группировать по типам объектов, либо не группировать вовсе, т.е. либо так

либо через интерфейсы и dynamic_cast.


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

Вы видите еще какие либо варианты?

Добавлено через 2 минуты и 33 секунды

Я не знаю как еще описать, Вы же все поняли

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

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

В принципе было бы неплохо, но это не так важно.


Скажем так: не избегая, а без перекомпиляции, так-как исходников у них нет.

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

 

Добавлено @ 16:52

к чему?

Добавлено @ 16:54

А какие могут быть еще варианты? Реализация функций в сторонней библиотеке должна содержаться в самой библиотеке и это должен быть либо виртуальный, либо статический метод какого-либо класса, либо команда (pattern command/функтор), что не очень приятно, так-как выделять по классу на каждую операцию будет накладно.

Добавлено @ 16:59
Самым простым и выполняющим все требования решением на данный момент мне видится интерфейсы и dynamic_cast, т.е. что-то такое

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

Добавлено @ 17:02
На самом деле я не вижу какие реальные привилегии мне дает собственная таблица функций.
Их надо регистрировать, что отнимает время и хоть чуть-чуть, но все же усложняет жизнь, а что дает взамен?

Это сообщение отредактировал(а) azesmcar - 14.11.2011, 17:03

mes

сейчас думаю над такой вариацией query interface-а.
пользователь запрашивает интерфейс, реализующий модифицирующие операции над объектом текущего типа. Если возвращается 0, значит модифицирующие операции не поддерживаются. 


но здесь есть два минуса.
1. в самой функции приходиться получать объект базового типа, так-что от cast-а это не избавляет. Думаю как бы обойти.
2. нет возможности реализовать для объекта функцию move, но не реализовывать скажем функцию rotate (хотя этот минус есть и в случае виртуальных обычных функций, но там интерфейс можно максимально разделить, а в данном случае это приведет к необходимости писать кучу кода).


Это сообщение отредактировал(а) azesmcar - 14.11.2011, 17:24

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


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


в таком выражении и не дает..  если вы о примере, то плюс дает не таблица функций, а разбиение на прослойки, где для каждой группы можно добавить свой обработчик. Чтоб лучше понять представьте что вместо print, у нас execute_action (iaction &);


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

чуть позже сделаю  пример с пояснением как я вижу вашу решение..

azesmcar, неплохо было бы, если бы Вы привели бы список по парочке разнотипных по смыслу команд .. 
так например сдвигающее воздействие над фигурой в принципе из одной группы команд.. 


Это сообщение отредактировал(а) mes - 14.11.2011, 18:14

вот каракас для допиливания :

http://liveworkspace.org/code/9c9ae402c782...be5c4d3264d0e35
как видите определение новой команды может быть всего лишь типа :

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

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

для полноценного тестового запуска нужно добавить сериализацию/десериализацию, но суть и так понятна.. 
если что может помочь в этом направлении так и не доведенная до конца тема :
http://forum.vingrad.ru/forum/topic-323593...ed-discoly.html

Это сообщение отредактировал(а) mes - 14.11.2011, 23:00

mes

У нас древний компилятор, boost-а нет...я смутно представляю чего мне будет стоить такая реализация.
Завтра с утра посмотрю повнимательнее что да как и отвечу.
Спасибо.

для начала определимся с лексиконом, чтоб удобно было делить по группом вводим понятия тип_примитива и вариант_примитива..
где тип : ifigure, а вариант : наследник ifigure (rect, circle).. вариант всего лишь реализует интерфейс ifigure и никакой обработки команд не имеет.
для обработки вводим еще связывующее звено, для нас это figure_commander .. commander`ы должны быть зарегистрированы в main_commander.. 

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

Добавлено через 34 секунды

так предупреждать надо было сразу 

Добавлено через 1 минуту и 47 секунд
сейчас поправлю ключевые места, чтоб видно было как для старого писать..
кода будет правда немножко побольше, как при разработке, так и при пользовании, но все ж..