QTimer :: SingleShot уволен после удаления объекта

Question

//Example class 
class A : pubic QObject 
{ 
    Q_OBJECT 
    void fun() { 
     Timer::SingleShot(10, timerSlot); //rough code 
    } 
    public slot: 
    void timerSlot(); 
} 

auto a = SharedPointer<A>(new A); 
a->fun(); 
a->reset(); //a deleted 

В этом случае после того, как объект удален и таймер уволен, выполнит ли он timerSlot()? Я получаю крайне редкий крах и не уверен, что из-за чего-то подозрительного в этой логике.

Answer 1

Даже если таймер срабатывает, он не запускает слот. В документах от ~QObject указано: All signals to and from the object are automatically disconnected, and any pending posted events for the object are removed from the event queue. Единственный способ вызывать A::timerSlot и удалять A одновременно, если вы используете потоки.

Answer 2

Редактировать: Этот ответ был в ответ на исходный вопрос, который не использовал QObject, но имел class A как автономный класс, наследующий ничего. Вопрос был позже отредактирован, сделав этот ответ устаревшим, но я оставлю его здесь, чтобы показать, что потребуется, если не использовать QObject.

---

Единственный способ, которым вы можете это сделать, - сохранить объект до тех пор, пока таймер не выстрелил. Например:

class A : enable_shared_from_this<A> { 
    void fun() { 
     QTimer::singleShot(10, bind(&A::timerSlot, shared_from_this())); 
    } 
public: 
    void timerSlot(); 
} 

auto a = SharedPointer<A>(new A); 
a->fun(); 
a->reset(); // a goes out of scope, but its referent is kept alive by the `QTimer`. 

Причина вышеуказанные работы является то, что вы захватить shared_ptr к class A при настройке таймера, и таймер будет держать на него (иначе он не может стрелять).

Если вам не нравится или не могут использовать последние C++ функции или увеличения:

struct Functor { 
    Functor(SharedPointer<A> a) : _a(a) {} 
    void operator() { a->timerSlot(); } 
    SharedPointer _a; 
}; 

class A { 
    void fun(shared_ptr<A> self) { 
     QTimer::singleShot(10, Functor(self)); 
    } 
public: 
    void timerSlot(); 
} 

auto a = SharedPointer<A>(new A); 
a->fun(a); 

Answer 3

Вы не обязаны отключать сигналы и слоты объекта перед его удалением.

QObject деструктор будет очищать устаревшие соединения сигнал-слот для вас, до тех пор, как вы:

1. Наследовать от QObject

2. Use the Q_OBJECT macro in your class definition

После этих соглашения обеспечивают, чтобы ваш объект излучал сигнал destroyed() при его удалении. Фактически это то, что использует система сигналов и слотов Qt для очистки оборванных ссылок.

Вы можете сами прослушать сигнал destroyed(), если хотите добавить код отладки для отслеживания объектов lifecycles.

(В зависимости от конкретной версии Qt/moc, которую вы используете, вполне возможно, что код с не-QObject с использованием слотов или класс, полученный QObject, который не имеет Q_OBJECT в своем заголовке, все еще будет компилироваться, но вызвать метод timerSlot(), который будет вызван на указателе мусора во время выполнения.)

Answer 4

Я получаю крайне редкое падение из-за таймер из объектов сферы, которые мне нужно стрелять только один раз. Я использую QTimer :: singleShot, который является статическим методом и не относится к экземпляру объекта QTimer, который я бы выпустил с контекстом, в который он подает сигнал.

Это, конечно, решается в QTimer класса и желаемое поведение контролируемого экземпляра класса таймера с нестатической QTimer::singleShot свойством, установленным в действительности.

// declaration 
    QScopedPointer<QTimer> m_timer; 

protected slots: 
    void onTimeout(); 

// usage 
m_timer.reset(new QTimer); 
m_timer->setSingleShot(true); 
QObject::connect(m_timer.data(), SIGNAL(timeout()), this, SLOT(onTimeout())); 
m_timer->start(requiredTimeout); 

Таким образом, авария не должна происходить из-за таймера, отпускаемого с помощью объекта контекста.

Answer 5

достичь определенности, остановить таймер себя:

class A : pubic QObject 
{ QTimer t; 
    A() { connect(Signal-Slots); } 
    ~A() { t.stop(); } 
    fun() { t.start(10); } 
    ... 
};