Здравствуйте, гость ( Вход | Регистрация )
BRE | Дата 14.6.2009, 14:54 |
Шутник ![]() Если происходят такие чудеса, то где гарантия, что использование проверки if( wnd ) вместо assert исправит ситуацию.... ![]() Но я все равно уверен, что в грамотно написанной программе никаких случайностей быть не может. Если человек пишить
и этот код работает в debug и сыпется в release, то это проблемы самого человека (его кода). Мне кажется тут не та же ситуация. Одно дело, когда данные должны быть в обязательном порядке валидные и совсем другое - parent(). У объекта может и не быть родителя, т.е. тут двойственная ситуация, которая не означает, что программа работает не правильно. Вот именно в этой ситуации использование assert оправдано. Во время разработки программист может забыть указать родителя или по ошибке в качестве парента будет указан объект другого класса. Во время отладочного запуска ему тут-же датут по рукам и он все исправит. После отладки данная проверка уже не нужна, мы уверены что парент тот который надо. Еще бывают ситуации, когда по логике работы программы объекты могут быть разными или их может не быть вообще, вот тогда нужно добавлять проверки, которые будут жить и работать всегда. НО только если это предусмотренно самой программой! С другой стороны дальнейшая работа приложения врятли будет корректной. Хотя, если это какой-нибудь не критичный участок типа дополнительного функционала в программе, которым пользователи могут и не пользоваться никогда, то зачем закрывать программу? У нас на работе в программе есть функции, которые заведомо не работают и постоянно выдают AV (программа на Delphi), но она прекрасно продолжает работать и мы не пользуемся этими функциями, чтобы не получать лишние варнинги. Если кусок программы не работает, то может более гуманно вставить заглушку с выводом сообщения типа "Куда ты тыкаешь, эта функция не реализована!". ![]() |
|
SABROG | Дата 14.6.2009, 14:34 |
Это как? Программа - это абсолютно строгая последовательность действий. Ни каких случайностей там быть не должно... ![]() Шутник ![]() К радости! Зачем мне тянуть в релиз код, который по умолчанию никогда не выполниться? И assert'ы как раз для таких проверок и придумались. Мне кажется тут не та же ситуация. Одно дело, когда данные должны быть в обязательном порядке валидные и совсем другое - parent(). У объекта может и не быть родителя, т.е. тут двойственная ситуация, которая не означает, что программа работает не правильно. С другой стороны дальнейшая работа приложения врятли будет корректной. Хотя, если это какой-нибудь не критичный участок типа дополнительного функционала в программе, которым пользователи могут и не пользоваться никогда, то зачем закрывать программу? У нас на работе в программе есть функции, которые заведомо не работают и постоянно выдают AV (программа на Delphi), но она прекрасно продолжает работать и мы не пользуемся этими функциями, чтобы не получать лишние варнинги. |
|
BRE | Дата 14.6.2009, 14:06 |
Но вот воссоздать ситуацию на этапе отладки зачастую сложная штука. Это как? Программа - это абсолютно строгая последовательность действий. Ни каких случайностей там быть не должно... ![]() К сожалению только в debug сборке. В релизе это ни варнинга ни аборта, а через 9 месяцев ребеночек появится ![]() К радости! Зачем мне тянуть в релиз код, который по умолчанию никогда не выполниться? И assert'ы как раз для таких проверок и придумались. |
|
SABROG | Дата 14.6.2009, 14:01 |
Она и не должна ничего писать в релизе, такие ошибки должны выявляться на этапе отладки. С точки зрения оптимизации понимаю, не надо сравнивать каждый раз через if. Но вот воссоздать ситуацию на этапе отладки зачастую сложная штука. Это варнинг и abort. К сожалению только в debug сборке. В релизе это ни варнинга ни аборта, а через 9 месяцев ребеночек появится ![]() |
|
BRE | Дата 14.6.2009, 13:06 |
Q_ASSERT ничего не пишет в консоль при release сборке, в любом случае программа продолжит своё выполнение и выпадет по AV. Она и не должна ничего писать в релизе, такие ошибки должны выявляться на этапе отладки. Кстати достаточно написать так Q_ASSERT(wnd); Свой код я так и пишу, никогда не делаю сравнение с 0. Либо if( wnd ), либо if( !wnd ). Но это вопросы стиля написания, у каждого свои предпочтения. ![]() но в любом случае это только лишь warning в debug сборке. Это варнинг и abort. |
|
SABROG | Дата 14.6.2009, 12:44 |
Если я правильно понял вопрос, то ты хочешь из Second получить доступ к родительскому окну?
Q_ASSERT ничего не пишет в консоль при release сборке, в любом случае программа продолжит своё выполнение и выпадет по AV. Кстати достаточно написать так Q_ASSERT(wnd);, но в любом случае это только лишь warning в debug сборке. |
|
Litkevich Yuriy | Дата 14.6.2009, 0:22 |
Метод parent описан в QObject и соответственно возвращает указатель на QObject. Пардон, я недосказал:Я имел в виду указатель на родителя parent, передаваемый в конструктор, вместо метода parent() см. код maxvanceffer в 13 сообщении. Но, как я и говорил - это способ для данного конкретного случая. У BRE - универсальный. |
|
maxvanceffer | Дата 13.6.2009, 23:26 |
Ура всем спосибо получилась по примеру BRE , пытался соединять раньше сигна со слотом из главного в ребёнка но не срабатывала. Но по совету BRE получилось !!! Еще поиграюсь сразными возожнастями .... щас читаю статейку об этом.... | |
BRE | Дата 13.6.2009, 22:45 |
2) Второй вариант, как и первый, только убрать приведение типа, и вызывать метод show (приведение не нужно т.к. это родной метод QWidget) Метод parent описан в QObject и соответственно возвращает указатель на QObject. Приведение типа все равно нужно, правда приводить можно к QWidget. Цитата QObject * QObject::parent () const |
|
Litkevich Yuriy | Дата 13.6.2009, 22:39 |
1) Один вариант тебе написал BRE. 2) Второй вариант, как и первый, только убрать приведение типа, и вызывать метод show (приведение не нужно т.к. это родной метод QWidget) Т.к. у тебя второе окно наследник от QDialog, то могут быть ещё два варианта: 3) Перед вызовом твоего диалога, соедени его сигнал void finished ( int result ) со слотом show первого окна. 4) А может стоит пользоваться модальным диалогом? Я сильно сомневаюсь, что основное окно будет мешать пользователю. А вот исчезновение главного окна а потом появление, т.е мелькание окон, явно его выведет из равновесия. signals: вот это зря. с таким именем, хоть и с другой сигнатурой, уже есть функция у базового класса (QWidget). Лучше придумай другое имя.void closeEvent(); |
|
Просмотр темы полностью (откроется в новом окне) | |
![]() |
Текстовая версия | Сейчас: 4.12.2023, 12:04 |