Приведение типов C++/QT Опции

[fsMark]

Писал недавно одному знакомому о приведении типов в QT, решил выложить на форум вдруг комунибудь будет полезно или ктонибудь дополнит(сам пишу на QT 4 месяца )
На мой взгляд картина выглядить слкдующим образом:

стандартная конструкция:
classA* A = new classA;
classB* B = (classB*)A;
приведет указатель на classA к указателю на classB, это стандартный способ приведения указателей унаследованный от языка C, при таком приведении не производиться никаких проверок не на этапе компиляции не на этапе исполнения со всеми вытекающими последствиями.

В C++ введенны следующие более тонкие конструкции:

classA* A = new classA;
classB* B = static_cast<classB*>A;
Эта конструкция приведет указатель на classA к Указателю на classB при том условии что класс classB является наследдником класса classA

classA* A = new classA;
classB* B = dynamic_cast<classB*>A;
Эта конструкция действует аналогично static_cast, отличие заключается в том что производиться проверка на принадлежность обекта на который сыллается А класу В, для проверки использукется информатция о типах времени выполнения(RTTI) которая естественно должна быть включена на этапе компилятции(в болщенстве современных компиляторов включена по умолчанию).
Если проверка завершается неудачно то dynamic_cast вернет нулевой указатель.
В некоторых компиляторах dynamic_cast может не работать через границы разделяемых библиотек.

QT предоставляет свое средство для приведения указателей заместо dynamic_cast:
qobject_cast аналогичен dynamic_cast для подклассов QObject(для остальных классов результат не определен), но он не зависит от RTTI и может работать через границы разделяемых библиотек.

вот пример из ассистента:
QObject *obj = new QTimer; // QTimer inherits QObject
QTimer *timer = qobject_cast<QTimer *>(obj);
// timer == (QObject *)obj
QAbstractButton *button = qobject_cast<QAbstractButton *>(obj);
// button == 0

Кроме того для приведения указателей на классы унаследованные от QGraphicsItem(не наследник QObject) существует qgraphicsitem_cast.

[Алексей1153]

Исправляйте репутацию.

готово!

==============================

моё ИМХО

1) использование static_cast иногда может быть вполне оправдано - для подстраховки на этапе компиляции.

2) Необходимость использования dynamic_cast:
a ) признак кривого проектирования. Равно как и явное приведение к void* и из него - тоже такой признак
b ) при поддержке чужого запутанного кода - это подстраховка в реалтайме (можно всегда результат каста проверить на ноль)
Поэтому лучше проектировать так, чтобы кастить через этот оператор не было необходимости.
Кроме того, для возможности применения dynamic_cast класс обязан иметь хотя бы одну виртуальную функцию, что не всегда приемлимо

3 ) Необходимость использования reinterpret_cast : см. п 2)a) . Но ещё иногда требуется, к примеру, при взамодействии с ранее написанным кодом на чистом си (пример - WinAPI , извещения WM_NOTIFY от стандартных контролов)

Критика принимается

Сообщение отредактировал Алексей1153 - 7.6.2012, 7:04