Форум на CrossPlatform.RU -> Ответ в Небольшие проблемы с QSharedPointer и Forward Declaration

Последние 10 сообщений [ в обратном порядке ]

SABROG	Дата 28.5.2010, 8:17
	Цитата(BRE @ 27.5.2010, 17:32) Если ты добавишь: #include "ui_widget.h" И как побочный эффект я потеряю все преимущества связанные с forward declaration, фиксированным размером указателя, скоростью компиляции и перекомпиляции всего приложения при изменении интерфейса.
BRE	Дата 27.5.2010, 16:32
	Цитата(SABROG @ 27.5.2010, 12:21) Логически ведь получается такая схема: - moc генерит .cpp файлы - компилятор собирает все модули Стало быть на втором этапе ему должно быть всё известно, moc же вызывается до компиляции, а не после. И moc и uic уже отработали, файл ui_widget.h уже сгенерирован. Если ты добавишь: #include "ui_widget.h" в widget.h, то все неоднозначности разрешаться и все скомпилируется. Forward declaration просто говорит компилятору, что такой класс/тип есть. Если использовать обычный указатель, то это будет работать, потому что компилятор знает размер указателя для любого типа (размер указателя на объект любого класса равен размеру указателя на void). А вот если для шаблона нужен размер объекта, то без полного описания класса компилятор определить его не может.
DEADHUNT	Дата 27.5.2010, 13:10
	Цитата(DIMEDROLL @ 27.5.2010, 13:13) посмотрю, а ты смотрел? подскажешь страничку или пункт? если в стандарте сказано что будет неопределённое поведение при forward declaration, то зачем писать такой код? и зачем советовать tr1 и boost? что трудно самому стандарт открыть? в 14.4.1 [Note: a template type argument may be an incomplete type (3.9). — end note ], значит всё предсказуемо, просто на исходниках кто-то писал про неопределённое поведение, вот я и загнался.
DIMEDROLL	Дата 27.5.2010, 12:13
	Цитата(DEADHUNT @ 27.5.2010, 11:59) стандарт посмотри там написано неопределённое поведение, но во многих компиляторах это разрешается. посмотрю, а ты смотрел? подскажешь страничку или пункт? если в стандарте сказано что будет неопределённое поведение при forward declaration, то зачем писать такой код? и зачем советовать tr1 и boost?
DEADHUNT	Дата 27.5.2010, 11:59
	Цитата(DIMEDROLL @ 27.5.2010, 12:51) так будут работать или undefined behavior? стандарт посмотри там написано неопределённое поведение, но во многих компиляторах это разрешается.
DIMEDROLL	Дата 27.5.2010, 11:51
	Цитата(DEADHUNT @ 27.5.2010, 7:42) будут. ... undefined behavior. так будут работать или undefined behavior?
SABROG	Дата 27.5.2010, 11:21
	Логически ведь получается такая схема: - moc генерит .cpp файлы - компилятор собирает все модули Стало быть на втором этапе ему должно быть всё известно, moc же вызывается до компиляции, а не после.
BRE	Дата 27.5.2010, 9:01
	Цитата(SABROG @ 27.5.2010, 9:48) Если это баг, то надо писать троллям, если нет, то смирюсь и пойду дальше. Компилятор не может развернуть шаблон не зная типов параметров. То, что нормально собирается пример с одним файлом - не удивительно, компилятор находит описание структуры, даже если она описана позже, но находится в одной единице компиляции (в одном файле).
SABROG	Дата 27.5.2010, 8:48
	Цитата(DEADHUNT @ 27.5.2010, 8:42) tr1 уже входит в C++0x. tr1 - technical report. По сути отчет от разработчиков компилятора о том, что уже готово из будущего стандарта (C++0x), который еще не вышел. Но когда он выйдет я сомневаюсь, что разработчики компиляторов сделают этот стандарт включеным "по умолчанию". Если они так поступят, то огромное количество приложений, поддержка, которых давно закончилась, просто перестанет собираться без какого-нибудь ключа типа "-std=c++98". Кроме того существуют платформы, где используются старые версии gcc (сделали один раз порт под платформу и забросили), на них конечно никакие программы на Qt написанные с использованием нового стандарта собираться не будут. Но я уже выбрал, что хотел, тема о другом. Если это баг, то надо писать троллям, если нет, то смирюсь и пойду дальше. --- Сделал так для проверки. Всё собирается без предупреждений. Пойду делать багрепорт. `#include <QtGui/QWidget> #if 0 #include <tr1/memory> #define QSharedPointer std::tr1::shared_ptr #endif`
DEADHUNT	Дата 27.5.2010, 7:42
	Цитата(SABROG @ 26.5.2010, 16:16) Первый тем, что std::tr1::shared_ptr. Второй тем, что boost. Ставить дополнительную библиотеку, когда есть QSharedPointer, нафига? tr1 уже входит в C++0x. boost.smart_pointers ничего не требует кроме заголовочных файлов и темболее многие библиотеки из boost добавляются в стандарт. Цитата(DIMEDROLL @ 26.5.2010, 16:50) предполагаю что и эти шаблоны не будут работать с forward declaration. будут. Цитата(DIMEDROLL @ 26.5.2010, 16:50) Насколько я понмю - шаблоны нельзя инициализировать неизвестным классом... undefined behavior.
Просмотр темы полностью (откроется в новом окне)