!Предполагается уже знакомая многим структура базовых и производных классов (указываю только защищенные члены, содержащие данные - в функциях ничего интересного нет; есть чисто виртуальные функции; 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 (но сам порядок перечисления фигур мы менять не можем, мы можем выбрать только способ задания конкретной фигуры); можно указать и общее количество фигур. Например, как-то так:
| Цитата |
n point [RGB для пера] x y line [RGB для пера] x1 y1 x2 y2 ellipse [RGB для пера] [RGB для кисти] [4 числа прямоугольника, в который вписан эллипс] rectangle [RGB для пера] [RGB для кисти] [RECT] |
| Цитата |
2 point 0 0 0 4 5 ellipse 34 34 65 234 231 198 4 3 6 8 |
Как несложно увидеть, мы знаем только общее количество фигур и не знаем заранее ни тип следующей фигуры, ни общее число фигур какого-то типа.
Собственно, в чем проблема...
Надо "просто" создать их этих объектов-фигур какую-то ... массивообразную структуру (т.е. так, чтобы с помощь индекса от 0 до n-1 мы могли обратиться к любому объекту, прочитать содержимое его членов, изменить его, поменять местами с каким-то другим элементом с известным номером).
Понятно, что все это связано с указателями на базовый класс - это основы динамического полиморфизма.
Можно было бы разбить файл на 4 условных части (сначала кол-во Point и их описания, потом кол-во Line и их описания, потом ... ) и создать 4 массива... Но это уже слишком упрощает задачу программиста и резко ограничивает свободу пользователя в выборе z-order-а фигур (предполагается, что изначально фигуры накладываются друг на друга в том порядке, в котором читаются; порядок сохраняется в бинарное дерево (как именно, я пока не думала) и потом может изменяться).
Я думала
создать массив из указателей на Figure (должно получиться - размер одного указателя известен, а знать размер наследника Figure (или самого Figure) нам не нужно)
узнать тип следующей фигуры
взять временную переменную такого типа, прочитать в нее данные из файла
скопировать данные этой переменной туда, куда показывает указатель текущего цикла
Но, естественно, ничего не получилось: указатель-то на Figure и копируются только те члены, которые есть в Figure, а специальные уточняющие члены (точки для Point и Line, цвет кисти и прямоугольник для FilledFigure) не появляются и просто опускаются...
Как можно на лету узнать тип (с этим мы справимся - в файле написано) и создать именно такой элемент массива? Не могу догадаться...
. Как приятно 
). Сначала он торжественно описывает, как появлялась RTTI, как она важна и насколько полезна, потом начинает с typeid() и класса type_info, потом ... пока не знаю. Но если пролистать главу, то "template" видно лишь в самом конце и совсем чуть-чуть: в пункте "применение dynamic_cast к шаблонным классам". Вот 
.
, вот это действительно стоило сделать.
.
. Ваши ценные комментарии я вполне понимаю.
! Это была правда