PDA

View Full Version : Dialog executes in debug build but not release



awhite1159
24th June 2008, 11:10
My apologies if this question is better suited in the newbie forum. Please let me know. I have a dialog that I am creating that works fine in debug mode but in release mode it locks up. I'm not really sure why but I suspect a pointer to Null somewhere. Any ideas?


/*
* newnetworkdialog.h
* bkupsim
*
* Created by Andrew White on 6/23/08.
* Copyright 2008 __MyCompanyName__. All rights reserved.
*
*/

#ifndef NEWNETWORKDIALOG_H
#define NEWNETWORKDIALOG_H

#include<QDialog>

class QFormLayout;
class QLineEdit;
class QComboBox;
class QDialogButtonBox;

class NewNetworkDialog : public QDialog {
Q_OBJECT
public:
NewNetworkDialog(QWidget* parent = 0);
signals:

private slots:
void accept();
void reject();

private:
QLineEdit* nameLineEdit;
QLineEdit* ipLineEdit;
QLineEdit* netmaskLineEdit;
QComboBox* thruputComboBox;
QFormLayout* formLayout;
QDialogButtonBox* okCancelButtonBox;

};

#endif
/*
* newnetworkdialog.cpp
* bkupsim
*
* Created by Andrew White on 6/23/08.
* Copyright 2008 __MyCompanyName__. All rights reserved.
*
*/

#include "newnetworkdialog.h"
#include<QtGui>

NewNetworkDialog::NewNetworkDialog(QWidget* parent) :
QDialog(parent) {

nameLineEdit = new QLineEdit;
ipLineEdit = new QLineEdit;
netmaskLineEdit = new QLineEdit;
thruputComboBox = new QComboBox;
formLayout = new QFormLayout;
formLayout->addRow(tr("Name:"), nameLineEdit);
formLayout->addRow(tr("IP Address:"), ipLineEdit);
formLayout->addRow(tr("Netmask:"), netmaskLineEdit);
formLayout->addRow(tr("Thruput Type:"), thruputComboBox);
thruputComboBox->addItem(tr("10-B-T"), 1000);
thruputComboBox->addItem(tr("100-B-T"), 10000);
thruputComboBox->addItem(tr("1000-B-T"), 100000);


okCancelButtonBox = new QDialogButtonBox(QDialogButtonBox::Ok
| QDialogButtonBox::Cancel);

formLayout->addRow(okCancelButtonBox);
setLayout(formLayout);
connect(okCancelButtonBox, SIGNAL(accepted()), this, SLOT(accept()));
connect(okCancelButtonBox, SIGNAL(rejected()), this, SLOT(reject()));
}

void NewNetworkDialog::accept() {
QDialog::accept();
}

void NewNetworkDialog::reject() {
QDialog::reject();
}

jpn
24th June 2008, 13:36
Does it lock up even if you use the dialog like this:


// main.cpp
#include <QApplication>
#include "newnetworkdialog.h"

int main(int argc, char* argv[])
{
QApplication app(argc, argv);
NewNetworkDialog dialog;
return dialog.exec();
}

The idea is to use the dialog alone and nothing else.

awhite1159
24th June 2008, 15:04
That works without a problem. So it might be the way I am instantiating the dialog:


dialog->show();
dialog->raise();
dialog->activateWindow();

I call this through a slot declared in my main window as a result of a signal from a menu option.

awhite1159
24th June 2008, 15:37
I found the problem. When I call the slot:


void MainWindow::newNetwork() {
if(!newnet)
newnet = new NewNetworkDialog(this);
newnet->exec();
}

I declared it in newnetworkdialog.h as:


QDialog* newnet;

I wrongly assumed it would initialize to zero. By adding to the MainWindow constructor:


newnet = 0;

It works now. My apologies as this is a basic C++ issue. But my question is why did it work in debug mode and would there be a better way to initialize the newnet to point to null?

jpn
24th June 2008, 16:48
Without getting bogged down into details, let's just say that compilers tend to optimize things in release mode. You should always initialize pointers because you cannot rely on that they would be initialized to any sane value like it might be the case in debug mode with some compilers. More details: Surviving the Release Version (http://www.codeproject.com/KB/debug/survivereleasever.aspx).

The correct way to initialize member variables in C++ is to use the initializer list:


SomeClass::SomeClass(/* args */)
: BaseClass(/* args */), memberPtr(0), memberVar(123, 456) // <--
{
}

One might argue about the readability versus:


SomeClass::SomeClass(/* args */)
: BaseClass(/* args */)
{
memberPtr = 0;
memberVar = SomeType(123, 456);
}

but the fact is that in the latter method the member object gets constructed twice: 1) by using it's default constructor and 2) in the constructor body. You might not want to do that at least in case of complex types.

awhite1159
24th June 2008, 18:51
Thanks JPN.