Доброе время суток снова, мои замечательные винградовцы  !

Предполагается уже знакомая многим структура базовых и производных классов (указываю только защищенные члены, содержащие данные - в функциях ничего интересного нет; есть чисто виртуальные функции; color - выше определенная структура: struct color (r,g,b;)):

• Figure {color fpen;}
  
  • Point {POINT p;}
  • Line {POINT p1, p2;}
  • FilledFigure {color fbrush; RECT rect;}
    
    • Ellipse
    • Rectangle
      (Ellipse и Rectangle разделены, т.к. у них будет разная реализация функций рисования и проверки принадлежности точки с заданными координатами фигуре)

В файле удобным для нас (и соответствующим иерархии классов) образом заданы фигуры типов Point, Line, Ellipse, Rectangle (но сам порядок перечисления фигур мы менять не можем, мы можем выбрать только способ задания конкретной фигуры); можно указать и общее количество фигур. Например, как-то так:


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

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

Можно было бы разбить файл на 4 условных части (сначала кол-во Point и их описания, потом кол-во Line и их описания, потом ... ) и создать 4 массива... Но это уже слишком упрощает задачу программиста и резко ограничивает свободу пользователя в выборе z-order-а фигур (предполагается, что изначально фигуры накладываются друг на друга в том порядке, в котором читаются; порядок сохраняется в бинарное дерево (как именно, я пока не думала) и потом может изменяться).

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

Но, естественно, ничего не получилось: указатель-то на Figure и копируются только те члены, которые есть в Figure, а специальные уточняющие члены (точки для Point и Line, цвет кисти и прямоугольник для FilledFigure) не появляются и просто опускаются...

Как можно на лету узнать тип (с этим мы справимся - в файле написано) и создать именно такой элемент массива? Не могу догадаться...

Factory?



пример использования.

убрал использование умных указателей

Это сообщение отредактировал(а) azesmcar - 17.7.2009, 08:43

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


Мне кажется, что Factory желательно оформить как singleton.

Это сообщение отредактировал(а) Леопольд - 16.7.2009, 19:02

Это всего лишь пример написаный на скорую руку, думаю что использование виртуального деструктора здесь очевидно.
А умные указатели убрал чтобы топикстартеру было легче понять код и чтобы потом не мучалась с хранением auto_ptr -а (именно он был использован как default smart pointer в параметре шаблона) в контейнере.


С чего это? А если потом две фабрики понадобиться весь код менять? Нафиг надо.

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

Если это будут две разные фабрики 
patterns::Factory<Base> factoryB;
patterns::Factory<AnotherBase> factoryA;
То это не проблема. А зачем две одинаковых? Проблема может быть из-за того что это не чистая фабрика, она ещё и память чистит. Я бы вынес это из фабрики. И пользовался бы shared_ptr<Base> в качестве возвращаемого значения Create.

Это сообщение отредактировал(а) Леопольд - 16.7.2009, 19:37

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

KasMP, В общем для реализации обычной фабрики, о которой шла речь выше, надо несколько Create-функций (одинаковой сигнатуры), поместить в (ассоциативный) массив и потом по названию/индексу вызывать подходящую функцию. Create-функцию зачастую удобно оформлять как статическую в классе, объект которого она создает.

Добавлено @ 19:44

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

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

Может понадобиться. Например в многопоточном приложении.


Эти фабрики...они такие  


Это сообщение отредактировал(а) azesmcar - 16.7.2009, 19:48

Если она только "плодит" объекты, то вроде нет проблем...

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

Мне кажется что shared_ptr тоже достаточно прост. 

Показалось что она ещё и удаляет все созданные ей объекты. Был неправ, каюсь...   

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

Проблема есть. Поищи в гугле std::map thread safety issues.


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

Ух ты, сколько тут всего написали  . Да еще подумали, чтобы мне было понятно и хорошо  . Как приятно    ...



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

Как всегда, мне понятно каждое слово и вообще понятно. Благодарю  .

Я вчера увидела у Герберта Шилдта главу 22 с гордым названием "динамическая идентификация типа и операторы приведения" (удивительно, что заметить ее раньше я не смогла ). Сначала он торжественно описывает, как появлялась RTTI, как она важна и насколько полезна, потом начинает с typeid() и класса type_info, потом ... пока не знаю. Но если пролистать главу, то "template" видно лишь в самом конце и совсем чуть-чуть: в пункте "применение dynamic_cast к шаблонным классам". Вот .

Да, понятно  .

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

Леопольд, странно, что репутация у тебя такая отрицательная (а репа даже в "-1" уже настораживает форумчан). Спасибо за все твои старания  .

еще есть boost::serialization - готовый к использованию сериализатор\десериализатор с различными форматтерами (простой для использования) раз пошла такая пьянка ....может стоит взглянуть на него.

Мне надо "общаться" только в трезвом состоянии. А то бываю черезчур резок, если спровоцирвать... 

Это сообщение отредактировал(а) Леопольд - 17.7.2009, 08:44

Добавил комментарии (в первом посте). Надеюсь поможет (с английским хорошо?), если что - спрашивайте, не стесняйтесь. 


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


Тут была тема про совмещение умных указателей и фабрики.

http://forum.vingrad.ru/forum/topic-250892/hl/factory/0.html
чтобы глаза не мозолить лишними страницами кода