LINUX.ORG.RU

[C++] Массив разных классов и массив ссылок на разные классы

 


0

0

Есть класс Rectangle (прямоугольник). У него есть размеры по x и y и координаты центра.

Наследованием созданы классы ColoredRectangle (цветной прямоугольник) и PatternedRectangle (прямоугольник с текстурой). У обоих есть функции Draw(), рисующие их.

Надо сделать массив (желательно, vector) rectangleMass, содержащий как цветные, так и текстурированные прямоугольники, чтобы потом пройтись по нему, вызывая для каждого элемента Draw. Также нужен массив (опять же, желательно vector), содержащий указатели на некоторые элементы из rectangleMass.

Это возможно?

★★★★★

Последнее исправление: Obey-Kun (всего исправлений: 1)
Ответ на: комментарий от anonymous

А что здесь быдлокодерского?

class Rectangle 
{ 
public: 
virtual void Draw() = 0; 
virtual void SetColor(){} 
};

ИМХО былокод имеет место быть.

1. SetColor() в базовом классе как я понял не нужен.

2. virtual void SetColor(){}. Объявление отдельно, реализация отдельно.

3. Если класс будет наследуемый то стоит стразу в базовом классе сделать виртуальный деструктор. Иначе словите много «радости»

Предлагаю свой вариант (для обсирания)

class Rectangle
{
public:
  double x; //Координаты центра
  double y; 
  double sx; //Размеры прямоугольника
  double sy;
  virtual ~Rectangle(); //ИМНО нужен
  virtual void Draw(); //метод рисования, можно абстрактный
};

//В векторе храним исключительно УКАЗАТЕЛИ а не сам класс
//ИМХО писать что-то вроде vector<Rectangle> надо с большой осторожностью
vector<Rectangle*> recv_arr; 

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

В векторе храним указатели всех экземпляров наследников от Rectangle. Если надо, то можно завести ещё несколько векторов с указателями некоторые экземпляры. ИМХО всегда лучше иметь что-то вроде «главного хранилища» и жизненный цикл объектов привязывать к жизненному циклу соответствующих указателей в этом хранилище. Это может помочь в контроле за жизненным циклом объектов.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

>2. virtual void SetColor(){}. Объявление отдельно, реализация отдельно.

Бред читой воды.

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

staseg ★★★★★
()
Ответ на: комментарий от staseg

>2. virtual void SetColor(){}. Объявление отдельно, реализация отдельно.

Бред читой воды.

Если не трудно, то объясните в чем «бредовость» раздельного объявления и реализации методов.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Если не трудно, то объясните в чем «бредовость» раздельного объявления и реализации методов.

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

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

virtual void someStuff(){} // пустой

int isReady()const{ // тривиальный
return this->ready;
}
staseg ★★★★★
()
Ответ на: комментарий от JackyTreehorn

>vector<shared_ptr<Rectangle> > recv_arr;

Плохо, что надо тащить Boost. И все равно надо быть осторожным, так как «подводные камни» остаются.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Плохо, что надо тащить Boost

ну напиши свой shared_ptr, или пользуй tr1

jtootf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.