Interfaces, abstract, concrete classes and QObject

Oleksandr Malyushytskyy

Not true for QWidgets, where parent is important regardless of memory management. Dialogs without a parent have a native handle, while those that do have a parent are (ordinarily) alien widgets.

Any widget regardless of parent can have a native handle.
Providing a parent to the QObject allocated on the stack may lead to deleting it twice. So QWidget which needs a parents should not be allocated on a stack.

Sorry, but no. Smart pointers aren't proper memory management, they are a tool that might facilitate proper management.

Smartpointers in C++ is basically only a way for an application to do a proper memory management in presence of exceptions.

kshegunov

@Oleksandr-Malyushytskyy said in Interfaces, abstract, concrete classes and QObject:

Any widget regardless of parent can have a native handle.

They can indeed, that's why I put "ordinarily" (i.e. usually) in parenthesis - most of the time they won't if you don't pass the appropriate attribute(s).

Providing a parent to the QObject allocated on the stack may lead to deleting it twice.

Yes, if you take special care not to put them in a stack order. A stack is first-in-last-out, so they (the objects) should be allocated in this fashion - parents come before children. Example:

QObject parent;
QObject child(&parent); //< Perfectly safe!

QObject child;
QObject parent;

child.setParent(&parent); //< Bad idea, don't do it it like this.

So QWidget which needs a parents should not be allocated on a stack.

Absolutely wrong! You can allocate them on the stack however much you like.

Smartpointers in C++ is basically only a way for an application to do a proper memory management in presence of exceptions.

Yes, that's what I wrote two posts up. And again, it's a tool, it doesn't sum up to "proper memory management". You can achieve proper memory management, albeit verbose, without smart pointers too. Plus I already noted that for Qt specifically you don't have exceptions thrown from the library.

Oleksandr Malyushytskyy

@kshegunov said in Interfaces, abstract, concrete classes and QObject:

QObject parent;
QObject child(&parent); //< Perfectly safe!

You make an assumption that parent is allocated on a stack. Why? If it is not? If it is destroyed before child goes out of scope?

I could continue to argue about other topics too, like if Qt code does not throw exceptions, it does not mean that exception may not be thrown in your application written with Qt or even from Qt code,
but I believe this topic is not a right place for such discussion, since it not does not help person who asked a question, while my original answer I believe should have helped him.

VRonin

This is the type of flaming I was talking about!
grabs popcorn

kshegunov

The original topic did include a question about leaking or not memory, so memory management is indeed relevant, although we are running a bit off topic I will concede.

You make an assumption that parent is allocated on a stack. Why? If it is not? If it is destroyed before child goes out of scope?

Then I'd argue the child should be a member of said parent:

class X : public QObject
{
    X(QObject * parent)
        : QObject(parent), child(this)
    {
    }

private:
    QObject child;
}

it does not mean that exception may not be thrown in your application written with Qt or even from Qt code,

Yes, and I did acknowledge that. Plus I reiterate, yet again, throw-safe code does not require smart pointers, they just make it easier to handle.

I'd also like to introduce yet another consideration here:
Creating a QObject (or derived class) instance with new (or equivalent std::make_unique, make_shared or w/e) amounts to allocating a void *, which is mighty inefficient.

@VRonin Nice glasses!

Defohin

I have to say, I'm enjoying it, not the flame, but the arguments, that's how we learn, experienced people discussing.

VRonin

@kshegunov said in Interfaces, abstract, concrete classes and QObject:

allocating a void *, which is mighty inefficient

mighty = 32/64 bits of memory?

kshegunov

@VRonin said in Interfaces, abstract, concrete classes and QObject:

mighty = 32/64 bits of memory?

+ the heavy look-up through the heap manager. ;)

A stack (or more correctly auto-storage) allocation takes a single instruction for the whole of the memory. It basically increments (or rather decrements) the stack pointer with a single number.

PS. To expand a bit, think of it like this:
Allocating on the stack is one decrement of the stack pointer. Allocating an object with members with auto-storage on the heap is done in one go in the heap manager - one look up. If you allocate each of the members on the heap you go through so many look ups in the heap.

VRonin

I'm still convince that that "mighty" is nothing compared to the inefficiencies I unknowingly introduce in production code because I'm not smart enough to think the O(1) algorithm; but I have to admit I'm a total ignorant as this level of technicality

kshegunov

Well, I suppose that argument holds too ... :)
I've been known to run rampaging against the heap on occasion, plus arguably it shouldn't matter in most cases. I'm arguing the principles here however ... (sounding like the devil's advocate now)