Program compiles but generates a segmentation fault.

fcarney

@kshegunov said in Program compiles but generates a segmentation fault.:

rather see descriptive (possibly long) names that speak to me

Definitely +1 on this point. With copy/paste and auto complete this really has no excuse not to use long variable names. It definitely makes thing more understandable.

The m_ prefix helps me understand things a bit quicker with or without the color coding. The part I like the most is functions that take variables that are intended to be set to a member.

void memberFunction(int index){
    m_index = index;
}

That way I can use the same variable name and show intent both ways.

kshegunov

@fcarney said in Program compiles but generates a segmentation fault.:

That way I can use the same variable name and show intent both ways.

You can be even more explicit without the prefix:

void SomeClass::someMember(int index)
{
    this->index = index;
}

Kent-Dorfman

This post is deleted!

jsulm

@Kent-Dorfman I don't think @kshegunov was talking about loop variables like i or j.
"one line comments inserted throughout to explain what the thing does" - everywhere where the variable is used?
It is highly subjective but I prefer variable/class names which are self-descriptive over short names.

kshegunov

@Kent-Dorfman, @jsulm

Indeed. As usual it's compromise between utility and brevity. I, personally, rarely have variables that are over the 12 chars too, but I'm much more lenient when it comes to the types or methods involved. Yes, it makes sense not to go too long on the variables, especially the locals, but when you call something out of the current scope it does help if you can tell what it does, hence my mention of the zpotrf, which really tells you nothing about what this does. If it were called choleskyHermitian, or if it were encapsulated in a proper type (i.e. a template or something) it'd make much more sense than just:

MyMatrixTypedef x = zpotrf(y, ....);

Example (excerpt from a test case):

HermiteQuadrature integral(maxOrder);
for (Hermite<real>::Order n = 1; n <= maxOrder; n++)  {
    Hermite<lreal> Hnm1(n - 1), Hn(n);
    xHermite xHn(n);

    real lhs = std::sqrt(2 * lreal(n)) * integral.evaluate(Hnm1);
    real rhs = integral.evaluate(xHn);
    if (isEven(n))
        QVERIFY(isEqual(lhs, rhs));        // Integrating an odd function gives zero
    else  {
        // ...
    }
}

You should be able to tell at a glance what this does, which is the point of a good style. If you can't then my style isn't good.

zlinux20

@Christian-Ehrlicher

I ended up using this

label = new QLabel("default label");
label->setText("This is Qt");

to get it to work. I also realize that I might need to learn a lot more about C++ classes and pointers before translating my Python gui code to C++ gui code.

Thank you.

JonB

@zlinux20
Are you saying you have written these two lines literally one after the other? What is the point of initializing the label with one string if you are going to change it to a different string immediately thereafter?

zlinux20

@JonB

Initially I had this

// mlabelwidget.cpp snippet
QLabel *label = new QLabel();
label->setText("This is Qt");
QWidget::update();

and this in my class declaration
//mlabelwidget.h snippet
class Mlabelwidget : public QWidget
{
  public:
    Mlabelwidget(QWidget *parent = 0);
    QLabel *label;
    void changeText(QString input);
};

when I found the hint of removing "QLabel *" from the declaration at this link I removed the "QLabel *" part and it worked i.e. there were no more segmentation faults. I wanted to report my progress and posted those lines that you mention. I left the second line in there from my earlier experiments, trying to initialize the QLabel. It is not needed now and my code is working as intended.

p.s. I am familiar with GUI Programming with Python Tkinter etc. I am learning just enough C++ at the moment to create a GUI program that needs to be an exe file as opposed to a Python script (client requirement).

Kent-Dorfman

FWIW, something else that seems conspicuously missing is that I'm not seeing the Q_OBJECT macro defined in your class definitions that inherit from QObject.

That macro is required so that the MOC system understands that the class is subject to Qt framework meta-processing. Just a wag, but revert to the original version and add the Q_OBJECT macro in the header file like follows:

MyClass: public QWidget {

Q_OBJECT
.
.
.
}

zlinux20

@Kent-Dorfman

Thank you for the hint. I did see it in some examples and noted it for future reference. I forgot all about it by the time I was working through (working/tutorial) examples I found online. I will be using the Q_OBJECT to change my existing (toy) program(s) to see how it works out.