Добрый вечер,

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

на что-то более вразумительное.
Здесь на помощь приходит полиморфизм, но
С одной стороны мне не очень хочется обогащать интерфейс несчастного класса object такими функциями, как copy, move, rotate...и так далее. Здесь по моему довольно неплохо справится шаблон visitor, это позволит добавлять новый функционал объектам, не затрагивая при этом самих объектов, но...
С другой стороны это фреймворк, другая группа может добавить свой тип объектов, который не обязательно можно перемещать или переворачивать, к тому же добавив новый объект, ему также придется добавлять новую функцию в моем visitor-е, чтобы компиляция прошла. Можно конечно добавить шаблонный метод visit, который будет принимать все остальное и генерировать исключения, но все равно другой группе придется ковыряться в моих "посетителях", на что мне в принципе наплевать, но чтобы сделать объект копируемым и модифицируемым, ему придется добавлять три функции в трех разных классах.
Выходит вроде как что с одной стороны хорошо, с другой плохо. Возможно здесь подойдет что-то вроде query interface-а, т.е.

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


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

Голосую за полиморфизм. Один раз посидишь, потратишь время, зато не будет дикого оверхеда. Подход должен быть удобный в использовании и очевидный при чтении. А то получится COM какой-то. 

Вопрос, насколько вероятно расширение состава объектов и насколько часто это может происходить.
Если редко, и визитеров предполагается немного, то я бы поставила на визитеров (с доп. шаблоном Visit и т.д.). 
С другой стороны, простая реализация визитера предполагает (как вариант), что в интерфейсе объекта есть ф-я типа Apply (Vis), а визитер наследуется от абстрактного класса, имеющего метод для каждого существующего класса. Таким образом, если конкретных визитеров много, добавление хотя бы одного типа объекта превращается в тихий ужас. Здесь и могут помочь примесные интерфейсы IMove, ICopy и т.д. Но код 

( в каждом месте, где нужно перемещать) - это тоже тихий ужас.
Поэтому можно совместить ежа с ужом, т.е. засунуть это дело в визитера, который может содержать методы для всех "стабильных" объектов, а может switch, а может просто преобразовывать obj к IMove... Зачем нам QueryInterface, если есть dynamic_cast. В общем в каждом случае визитера можно реализовывать как удобно. Есть же не только линейные иерархии. Например, полигон - это та же полилиния, но замкнутая, и т.д. Это, конечно, не совсем визитер уже будет, скорее просто некий функциональный объект, напускаемый на фигуры... Но от необходимости добавлять в интерфейс объекта все эти Move точно избавит.

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

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

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




Это сообщение отредактировал(а) mes - 10.11.2011, 19:05

Лучше не примеры, а UML того, что есть сейчас: общая и детальная.

Ну я, собственно, обертку и предложила... и комбинацию...  

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

не хотелось сразу грузить тему большим количество деталей, а то вдруг не прочтут  

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

Операций свыше десятка, объектов тоже немало, я затрудняюсь ответить чего здесь больше.
Желательно максимально облегчить труд другим группам, при добавлении новых объектов, но при этом не потерять красоты решения.
Я сейчас не вспомню все типов и операций, но пусть это будет десяток объектов и операции copy, move, rotate, scale, split, save.
Новые команды в принципе добавляются не так часто, объекты тоже, но объекты в основном добавляются совершенно другой группой и труд им желательно максимально облегчить, будет не совсем приятно заставлять их копаться в наших посетителях, это все таки фреймворк и должен предоставлять удобные средства для расширения.


А я ни о чем другом и не писал, все варианты в так или иначе реализуют полиморфизм. Вопрос в том, как его реализовать.


Вот об этом я и думаю, как бы скомбинировать.


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

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

Добавлено через 2 минуты и 35 секунд
какие принципиально отличительные от геометрических фигур бывают объекты, которые разделяют с мими часть команд ?

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


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

Это сообщение отредактировал(а) azesmcar - 10.11.2011, 21:53

azesmcar, я имел ввиду унифицированный базовый интерфейс.

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

Добавлено через 9 минут и 4 секунды
azesmcar, естественно, основной базовый класс все в себе не хранит, от него идет несколько абстрактных веток, чтобы разделить объекты по логическим типам и конкретным возможным операциям. Иначе это даже логичным назвать нельзя. Ведь что общего между стрелкой и засечкой со значением на линейке, ГРУБО ГОВОРЯ, кроме метода, скажем, draw? На мой взгляд, подводить все объекты под один базовый тип, это очень сомнительное удовольствие.

Это сообщение отредактировал(а) spyswamp - 10.11.2011, 23:27

тогда делить надо не по сущностям, а по функционалу.. 

например так :


на скорую руку но суть я думаю видна.. 


Добавлено @ 23:56

а должен ли быть этот метод, тоже вопрос..


Это сообщение отредактировал(а) mes - 11.11.2011, 01:45

1. выделено понятие блок с которым можно проводить некоторе кол-во операций
2. возможность операций определяется дескриптором
3. позволено создание нового типа фигуры, путем определения дескриптора
и регистрации необходимых методов, как например figure_render_method..
4. uid  позволяет связывать методы разных производителей.. 

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

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


согласен  
потому чистый visitor не подходит.


Думаю такое разделение на "стабильных" и не "стабильных" сильно затруднит понимание и чтение кода.


проект огромен, так что задача сложна  


по какой причине?


Сложно сказать. У нас редко добавляется и то и другое, но скорее всего так и есть. Методы добавляются редко, объекты добавляют другие, так-что мы часто и не в курсе, это уже другой продукт.


нет, но это уже совсем другая задача.


Это сообщение отредактировал(а) azesmcar - 11.11.2011, 09:36

  кто то кого то не понимает или оба друг друга.. 

Это сообщение отредактировал(а) math64 - 11.11.2011, 10:01

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

Я наверное не поняла всю сложность задачи,.. потому что по-моему все просто. Каждому типу объекта задается уникальный идентификатор. Далее регистрируем наборы функций для каждого типа (устанавливаем соответствие идентификатор-типа -> функция-делания-чего-то). Теперь общая функция, например copy, будет смотреть, какой объект к ней пришел, и вызывать соответствующую ему функцию копирования или пытаться выполнить какую-то операцию по умолчанию (попытаться самой провести копирование, или бросить эксепшн Ахтунг, или еще что-нибудь).

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

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

Добавлено через 6 минут и 21 секунду

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

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

Добавлено через 10 минут и 45 секунд

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

math64
Этих IMovable, IRotatable и всего остального будет слишком много, чтобы пихать их в параметры функции.


Мне самом не нравится, просто интересует и Ваше мнение. Мне оно не нравится по той же причине.


Про какую?  


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


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

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

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

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

Можешь реализовать и с отдельными visit(IMovable), visit(IRotatable), и т.д.  - eсли не смущает то, что если объект поддерживает несколько интерфейсов, visit() придётся вызывать несколько раз, по разу для каждого интерфейса.
Главное определить набор интерфейсов так, чтобы при добавлении нового класса не нужно было добавлять нового интерфейса.

Такое ощущение, что кто-то недавно прочитал про Visitor и сразу бросился им загромождать код. -) Уж извините, такое впечатление сложилось.

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


если методы добавляются редко лучше использовать visitor. query interface-подобные решения не дают возможности привычного статического контроля.


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

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

мне нравится способ, примененный в boost::operators.

Добавлено через 3 минуты и 39 секунд
при  таком подходе вам при добавлении метода надо будет только поменять шаблоны.

Читал о нем очень давно и кстати вторую страницу пишу о том, что это решение мне не нравится. Привел в качестве рассматриваемых решений.


не совсем понял.


имелось ввиду, что и классов и функций достаточно много.


т.е. Вы за

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


Вы про CRTP? А как это здесь поможет?

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


Это сообщение отредактировал(а) azesmcar - 11.11.2011, 10:59

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

Читал котда-то давно статью в "Мир ПК", в каком номере не помню, про модифакцию патерна Visitor с возможностью добавления новых посещаемых классов, но реализация довольно сложная - для того, чтобы пользоваться новыми классами в модифицированном Visitor. их нужно регистрировать.

Регистратор прикрутить как раз несложно. Но проблема в том, что при добавлении нового типа объектов, существующие визиторы о них ничего не узнают (кроме факта существования, регистрация ничего не добавит). Как сделать DoSomething с объектом неизвестной породы? Только вызвать его соответствующий виртуальный метод. А методы плодить на все случаи жизни не хочется. Можно сделать что-то типа Invoke с параметром "заданное действие". И пусть объект решает, поддерживает он это действие или ну его нафик. Вот только действие передавать придется либо идентификатором, либо каким-то классом-тэгом и в конечной реализации возникнут if или switch...

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

если набор операций может меняться (пользователем), то можно использовать либо visitor либо query_interface. в этом случае я за первое. но у Вас как я понял пользователи только классы добавляют, но не методы.


я не про механизм CRTP, я про идею расширения класса методами (которая может использовать CRTP как средство, но может и иначе).
у авторов boost::operators, на мой взгляд, получилось изящно.

нет, они определяют типы и операции с ними.


т.е. в итоге получается, что базовый интерфейс должен поддерживать операции move, rotate, copy ... и так далее, или должны быть интерфейсы imovable, irotatable, icopyable...
а пользователь сам решает, какие интерфейсы он будет поддерживать. Это приводит нас опять таки к query interface, в том или ином виде.


не совсем представляю как это можно применить к текущей задаче?

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

видимо я не вполне понял Вашу задачу. прочитал еще раз, внимательно, но нового не увидел.

давайте на примере:
пользователь определил новый тип объекта "пирог" и операцию над ним "съесть"

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

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

Попробую упростить задачу до примера.

Начну с нуля.

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

Вот иерархия классов:


С объектами можно производить некоторые операции, например копировать или перемещать. Возьмем для примера копирование.
Копирование по сути это текстовая сериализация объекта, далее этот текст помещается в буфер обмена.
Далее.
Группа B используется библиотеку в своем проекте, они добавлают новый тип объектов - точка. Они добавляют свой класс, наследник от figure_base и регистрируют его в библиотеке, далее они должны реализовать копирование объекта типа point.
Теперь о реализации.
Реализовать это можно многими способами, дело в том, чтобы выбрать самый подходящий.

1. Самый тупой способ - поместить все возможные функции в базовый класс figure_base, т.е. поместить туда функцию copy с default реализацией.

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

2. Более цивильный способ, разделить все на интерфейсы, т.е. добавить интерфейс icopyable, imovable... и так далее, а потом проверять, реализует ли класс этот интерфейс с помощью dynamic_cast-а. В итоге получается queryInterface. Недостаток подхода в том, что получается нагромождение всех функций в одном классе, который должен поддерживать и перемещение и копирование и поворот и многое другое. Чем больше функций, тем больше нагромождение, хотя интерфейс базового класса в этом случае не засоряется. Еще один минус подхода в медленной работе самого dynamic_cast-а.

3. С помощью вышеупомянутого шаблона visitor. В принципе все удобно, все разделено по функциональности, надо поменять функцию copy - меняем один класс, можно добавлять функции не меняя интерфейс самих классов. Недостаток в данном случае заключается в том, что при реализации копирование для объектов типа point, программисту придется лезть в нашу библиотеку и менять исходники, что не очень приятно. Желательно, чтобы его расширение было самодостаточно и не требовало модификаций нашего кода.

Надеюсь смог нормально описать.


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

или таблицы.. 


  , если надо чтоб "визетеры" могли быть динамически расширяемыми..

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

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

Добавлено через 5 минут и 59 секунд

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

Нет, регистрировался не просто класс, а связка его с методом Посетителя - точно не помню как.
Что-то похожее на это (но вряд ли это):

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


конечно. для решения этой проблемы существует классификация и декомпозиция. 

почитал дальше, вроде разобрался)))

кажется, проблема заключается не в наследовании и операциях, а в том, о чем Вы не упоминаете: операции производятся ядром над объектами базового класса, и нет возможности узнать какие именно интерфейсы реализуются классом.
скажем, end-user выбирает правой кнопкой мыши объект, и контекстное меню должно отобразить доступные операции.
если новые объекты подключаются на этапе компиляции, это можно решить статической проверкой. остальное сделает компилятор. 
если интерфейс нужно определять динамически, то либо callback (эдакие динамические visitorы) либо query-interface. принципиальной разницы в этом случае не вижу.

если я все правильно понял, и речь идет о статической задаче (периода компиляции), то MP (типа is_function_member<>)

Добавлено через 2 минуты и 32 секунды
а статические посетители применяются, если набор операций не предопределен. у Вас это не так

несколько важных моментов упущено.. сейчас попробую выудить их.. 

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

о полиморфности ни слова.. 


динамически добавляют ?

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

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

про АОП читал, но пока его не понимаю, поэтому в этой связи ничего не могу сказать..

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

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

А какие здесь нужны слова?


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


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

Добавлено через 1 минуту и 56 секунд

не совсем понял мысль. Почему нет такой возможности? Есть dynamic_cast. На данный момент так и сделано, проверяется реальный тип и вызывается соответствующая функция для этого типа. Цель как раз в том, чтобы избавиться от этого.

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

ну предложите четвертый, мне мои 3 тоже не нравятся  

немножко переформулирую.. 

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

так правильно ?

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

и при добавлении вынуждены перекомпилировать библиотеку ? или ж это не желательно ?



Это сообщение отредактировал(а) mes - 11.11.2011, 15:20

А зачем это нужно? Они же не меняют наших исходников.

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

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

а, в этом смысле...ну в принципе не желательно, но это возможно.

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

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




Это сообщение отредактировал(а) mes - 11.11.2011, 15:32

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

угу тем более что  библиотека для работы с полиморфными объектами..

Добавлено через 2 минуты и 35 секунд
но тогда надо будет ввести свою систему типов.. (или просто uid, если предполагается взаимодействие выходящее за границы приложения.. например по сети)

т.е. query_interface?

Добавлено через 1 минуту и 47 секунд

нет, этого не предполагается.

это можно, да. но это уже не полиморфизм, а огромный switch. если бы он Вам нравился, темы не было б
С++ статически типизирован, а dynamic_cast не добавляет динамичности в полной мере, эт только костыль


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


Йес!!   я о том и говорил. 
хорошо бы иметь больше информации об архитектуре проекта, о том как фреймворк связывается с кодом пользователей.
Если пользователи просто пишут расширения к откомпилированному коду, видимо без query-interface в каком-то его виде не обойтись. изобретёте еще один COM.
когда я приводил в пример boost::operators, имелось в виду, что проект компилируется целиком, т.е. ваш код и пользовательский

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

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

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

Примерно так оно и должно быть.

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

Вот именно  

http://liveworkspace.org/code/045bcd682434...0273f990d385bb7

Добавлено через 3 минуты и 40 секунд
a, b пользовательские типы.. пользователь также должен до использования своих типов проивести регистрацию (init)..
писалась на скорую руку, чтоб передать идею..  также использовал голый ид, но можно это приукрасить, если нижно..

Добавлено через 5 минут и 44 секунды
пример - база для реализации алгоритмов copy/paste..

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

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

Добавлено через 3 минуты и 51 секунду
 это АОП-way

а у С++ вообще с динамикой плохо, хорошо что руки не связывает и позволяет выкрутится обходными вариантами..

 ну тогда можно притянуть его и сюда 

разгрузив через список типов..    

где то так :
http://liveworkspace.org/code/0532d48b65fd...f0e78f2ba25ee9f

Это сообщение отредактировал(а) mes - 11.11.2011, 17:52

azesmcar, медитирую над этим примером

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

mes

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




не понял вопроса. что откуда возникло?

с чего это взяли ?

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

не понятно что делает выражение, процитированное baldina

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

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

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

функции это вы o serialize  или o serialize_fn<T> ?

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

глобальными или глобально видимыми ? 

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

собственно и я об этом. хочу понять задачу

Если в ваш пример с сериализатором переписать так, чтобы можно было его использовать не только с сериализатором, но и с перемещением, вращением, перекрашиванием и др. визиторами (но избавившись от getId() ) - получится примерно то, что было в журнале "Мир ПК"

подкорректируем задачу.. 

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


Это сообщение отредактировал(а) mes - 11.11.2011, 22:05

вот решение с комбинацией различных подходов :
http://liveworkspace.org/code/6148d7bc1a09...f9f74430ebd53c4

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

немного изменил завязку (регистрацию),  пододвинув ее в сторону си идеологии :
http://liveworkspace.org/code/c76143b44b1e...126584d06c5f01f

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

уже лучше - регистрировать нужно не отдельные классы, а модули.

отличная идея! правда для моей задачи ;)

math64, какую задачу озвучил, ту и решал 

а регистрятся, кстати, не классы, а колбяк-функции 


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

mes

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