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

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

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

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

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

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

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

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

int isReady()const{ // тривиальный
return this->ready;
}

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

Расширяемость не нужна, т.к. матмодель вполне определённая. А скорость важна, т.к. эта модель пишется на замену старой и тормозной.

> А скорость важна, т.к. эта модель пишется на замену старой и тормозной.

а ООП тут точно надо?

а зачем тут делать указатель на элемент вектора? копируешь указатель на сам объект и все

У меня это так реализовано (пока без всяких virtual функций, пока с базовым классом экспериментирую):

class Cell
{
    vector<NearCell> nearCells;
    struct NearCell
    {
        Cell *cellPointer;
        double contactArea;		//площадь контакта
        short axe;			//по какой оси (x,y,z)
    };
    vector<double> dimensions;	//массив размеров ячейки по осям (r)
    double volume;		//объём (ν)
public:
    ...
};

нормально?

> а ООП тут точно надо?

Да, т.к. мне нужен опыт ООП. Потом будет писаться похожая модель, где ООП точно понадобится.

> QI

Можно ссылку на ман? Гугл не гуглит.

это аналог dynamic_cast с похожей записью:

I_Connection* pConn = QI( pObj, I_Connection );

но оно пока тебе не надо

> нормально?

лень уже придираться :) ( ушел спать )

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

Но блин, про виртуальные деструкторы то забывать не нужно, это в любом случае длинные грабли. Впрочем если компилить с -wall -werror то такие ошибки не допустишь

Эт да :) Про них забыл.

vector<shared_ptr<Rectangle> > recv_arr;

> лень уже придираться :) ( ушел спать )

спокойной ночи, попридирайся потом плз)

>http://en.wikipedia.org/wiki/Query_Interface
по ссылке COM, это точно работает под линуксом?

>по ссылке COM, это точно работает под линуксом?
В wine запросто.

>vector<shared_ptr<Rectangle> > recv_arr;

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

Я бы вынес метод Draw() в отдельный интерфейс IDrawable и унаследовал Reactangle от него.

бери книги и учи основы

+1

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

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

> по ссылке COM, это точно работает под линуксом?

по ссылке описан принцип - а его реализация никак не отличается, что в виндовс, что в линукс