Program crashes when Canon ball reaches "water"

[MongKong]

Oh wow, that looks much better and easier to do, thank you !! Tho may i just ask, What is the point of having & operator at the beginning of QObject::destroyed and Ship:: onCannonBallDestroyed ? And why do you have to call onCannonballDestroyed using scope, if the method is part of the class Ship?

[d_stranz]

What is the point of having & operator at the beginning of QObject:: destroyed and Ship:: onCannonBallDestroyed

connect( canonball, &QObject::destroyed, this, &Ship::onCannonballDestroyed );

connect( canonball, &QObject::destroyed, this, &Ship::onCannonballDestroyed );

To copy to clipboard, switch view to plain text mode 

This is the new, type-safe form of QObject::connect(), which uses the "pointer to member function" style of giving the signal and slot pair. "&QObject:: destroyed" is the address of (pointer to) the "destroyed" signal (a member function) of the QObject class.

It is better to use this new style instead of the old one:

connect( cannonball, SIGNAL( destroyed( QObject * ), this, SLOT( onCannonballDestroyed( QObject * ) ) );

connect( cannonball, SIGNAL( destroyed( QObject * ), this, SLOT( onCannonballDestroyed( QObject * ) ) );

To copy to clipboard, switch view to plain text mode 

because the new style will not compile if you give the wrong arguments. The old style will compile, but will fail at run time if you give it the wrong arguments. That isn't so good, because unless you read the messages coming from the runtime output in the debugger, you will not know that the connect() failed and will wonder why your app isn't handling the signals in the way you think it should be.

[MongKong]

Oh i see, then i believe this works with timers aswell and timeout() method?

[anda_skoa]

Just as added info: the life time of a QObject can also be tracked with a QPointer

class Ship : public QObject
{
private:
    QPointer<Canon> m_cannonBall;
};

class Ship : public QObject
{
private:
    QPointer<Canon> m_cannonBall;
};

To copy to clipboard, switch view to plain text mode 

void Ship::fireCannonball()
{
    if ( canFireCannon() )  
    {
        m_cannonBall = new Canon( this );
    }
}
 
bool  Ship::canFireCannon()
{
   return m_cannonBall.isNull();
}

void Ship::fireCannonball()
{
    if ( canFireCannon() )  
    {
        m_cannonBall = new Canon( this );
    }
}

bool  Ship::canFireCannon()
{
   return m_cannonBall.isNull();
}

To copy to clipboard, switch view to plain text mode 

I.e. a QPointer tracks the QObject it is holding and resets itself to nullptr if the object is deleted

Cheers,
_

[d_stranz]

Thanks, anda_skoa. I've learned something new. QPointer<> is a bit more useful in this circumstance and leads to less code and overhead.

As I understand the docs, QPointer<> does not do reference counting in the way that std:: shared_ptr<> does. Also unlike shared_ptr, QPointer is not responsible for the lifetime of its object pointer. This also implies that you could potentially have several QPointer instances wrapping the same QObject pointer, correct? Presumably all of them connect to the same QObject:: destroyed() signal, and would simply set their internal copy of the pointer to null.

I will have to think of a good use case for this.

Oh i see, then i believe this works with timers aswell and timeout() method?

connect( myTimer, &QTimer::timeout, this, &ThisClass::onTimeout );

connect( myTimer, &QTimer::timeout, this, &ThisClass::onTimeout );

To copy to clipboard, switch view to plain text mode 

(Of course, substitute the real name of your class for "ThisClass")

connect( myTimer, &QTimer::timeout, [=]() { cannonball->deleteLater(); } );

connect( myTimer, &QTimer::timeout, [=]() { cannonball->deleteLater(); } );

To copy to clipboard, switch view to plain text mode 

Works with lambdas, too.

[anda_skoa]

Thanks, anda_skoa. I've learned something new.

As I understand the docs, QPointer<> does not do reference counting in the way that std:: shared_ptr<> does.
Also unlike shared_ptr, QPointer is not responsible for the lifetime of its object pointer.

In terms of smart pointers you can think of QPointer as a weak-pointer, created from a shared-pointer inside the object itself.

This also implies that you could potentially have several QPointer instances wrapping the same QObject pointer, correct?

Yes, correct.

Presumably all of them connect to the same QObject:: destroyed() signal, and would simply set their internal copy of the pointer to null.

It is a bit more sophisticated than that

Originally the implementation used some Qt internal functions to register the QPointer instances with the objects they were holding and the object would then notify the pointers as part of their destruction code.
I.e. without going through the signal mechansim (as that would have required QPointer to be a QObject).

The internals of the implementation changed and now literally uses a QWeakPointer for storing and monitoring.

I will have to think of a good use case for this.

Super useful in many circumstances.

Cheers,
_

[MongKong]

d_stranz and anda_skoa thank you both for help and advices, i appreciate it a lot thank you again !!!!!