Cascades Development

[paiki]

I was writing my app without it, but some samples and examples use it.

Since I'm not a  C/QML Developer, I have no idea if this is something from one of them, or it's something from Cascade, anyone have a logical explanation for this?  What it really does? Is there any use for this code-piece?

Example from: https://developer.blackberry.com/cascades/documentation/dev/integrating_cpp_qml/index.html

using namespace bb::cascades;
  
TestApp::TestApp(bb::cascades::Application *app) : QObject(app)
{
    QmlDocument *qml = QmlDocument::create("asset:///main.qml").parent(this);
    qml->setContextProperty("injection", this);
    AbstractPane *root = qml->createRootObject<AbstractPane>();
    app->setScene(root);
}

[simon_hain · Accepted solution]

this means a property of the class is initialized with a parameter, it is called initialization list.
see
http://www.parashift.com/c++-faq/init-lists.html

in this specific case the TestApp is a QObject, and its parent is set to the app object. you can read more about that feature here:
http://doc.qt.digia.com/qt/objecttrees.html

[Zmey]

Just a little clarification:

QObject is TestApp's base class.

Child class (TestApp in this case) has to call parent's constructor to initialize the parent too.

If you don't call it explicitly in initializers list, the default base class constructor will be called. Default constructor in this case will initialize the parent to NULL, but "app" should be set as parent, so we call the base class constructor explicitly supplying neccessary arguments.

For details on this, please check C++ class inheritance.

[paiki]

Thanks, I think I understood, I'll wait my head stop spinning so I can make sure of that.

[smcveigh]

The reason you'll want to use this is because when Qt object trees are destroyed and cleaned-up, the parents destroy their children.This way, cleanup happens in a controlled manner.  Earlier sample code tended to instantiate the application on the stack, which would cause it to be destroyed when it goes out of scope when main() exits.  I think this can lead to some double-destruction happening if it is also attached to a parent object, so it is probably best these days to do something like shown here:

https://github.com/blackberry/Cascades-Community-Samples/blob/master/HelloCamera/src/main.cpp

note that I am allocating my class using new, but then not tracking it anywhere.. this is because the parent object is tracking it for me and will destroy it when the time comes.

If you look back in the commit history, you'll see that I used to do it differently:

https://github.com/blackberry/Cascades-Community-Samples/blob/0d4c2c3f0328310b5b6cfe707bf1b0748d9eaa...

the downside with this approach is that "app" and "mainApp" both go out of scope at the end of main(), and I have no control over the order that their destructors will be called.  Things could get messy if I had set mainApp's parent object to "app" when destructors get called.

Cheers,

Sean

[Zmey]

Hi Sean,

The destructors are guaranteed to be called in reverse order of construction, so mainApp would be destroyed first in previous example.

[smcveigh]

really?

{

   Class1 a;

   Class2 b;

}

you're saying that C++ guarantees that b is destroyed before a when this block ends?  It hadn't bothered to research this.  (EDIT: yup, this is what C++ guarantees)   Still dangerous, as simply re-arranging declaration could cause grief, especially if one of those classes is set to destroy the other instance.

[Zmey]

I agree. The new example is more consistent with Qt design, I just wanted to say that the first one was technically correct.