Qt Observer-Type Pattern Using Signals and Slots
-
I'm interested in finding from others how you have solved a pretty simple problem.
I have many
QObjects
andQWidgets
. Each of these has a data buffer, varying in type depending on what information it is to hold. All data comes from a single repository but specific data gets farmed out to theseQObjects
andQWidgets
.At certain points in time, I want to clear all buffers from all objects pseudo-instantaneously.
I've thought about having a base class similar to the following pseudo-code:
class BaseClassController { function registerBaseClass(BaseClass *obj) { connect(this, SIGNAL(clearBuffers()), obj, SLOT(clearBuffers()); } private BaseClassController() { } static BaseClassController& instance() { static BaseClassController *inst = nullptr; if (!inst) inst = new BaseClassController(); return *inst; } signal clearBuffers(); } class BaseClass { BaseClass() { BaseClassController::instance().registerBaseClass(this); } virtual slot clearBuffers() { // Clears the buffer for this instance } }
Then when I want to clear ALL buffers, I just need to
emit clearBuffers
from theBaseClassController
Obviously, the singleton here isn't thread-safe but would this be an obvious way to achieve what I want or is there a much better solution or a more out-the-box solution to this? Or am I barking completely up the wrong tree?
Thanks
-
I'm interested in finding from others how you have solved a pretty simple problem.
I have many
QObjects
andQWidgets
. Each of these has a data buffer, varying in type depending on what information it is to hold. All data comes from a single repository but specific data gets farmed out to theseQObjects
andQWidgets
.At certain points in time, I want to clear all buffers from all objects pseudo-instantaneously.
I've thought about having a base class similar to the following pseudo-code:
class BaseClassController { function registerBaseClass(BaseClass *obj) { connect(this, SIGNAL(clearBuffers()), obj, SLOT(clearBuffers()); } private BaseClassController() { } static BaseClassController& instance() { static BaseClassController *inst = nullptr; if (!inst) inst = new BaseClassController(); return *inst; } signal clearBuffers(); } class BaseClass { BaseClass() { BaseClassController::instance().registerBaseClass(this); } virtual slot clearBuffers() { // Clears the buffer for this instance } }
Then when I want to clear ALL buffers, I just need to
emit clearBuffers
from theBaseClassController
Obviously, the singleton here isn't thread-safe but would this be an obvious way to achieve what I want or is there a much better solution or a more out-the-box solution to this? Or am I barking completely up the wrong tree?
Thanks
-
I'm interested in finding from others how you have solved a pretty simple problem.
I have many
QObjects
andQWidgets
. Each of these has a data buffer, varying in type depending on what information it is to hold. All data comes from a single repository but specific data gets farmed out to theseQObjects
andQWidgets
.At certain points in time, I want to clear all buffers from all objects pseudo-instantaneously.
I've thought about having a base class similar to the following pseudo-code:
class BaseClassController { function registerBaseClass(BaseClass *obj) { connect(this, SIGNAL(clearBuffers()), obj, SLOT(clearBuffers()); } private BaseClassController() { } static BaseClassController& instance() { static BaseClassController *inst = nullptr; if (!inst) inst = new BaseClassController(); return *inst; } signal clearBuffers(); } class BaseClass { BaseClass() { BaseClassController::instance().registerBaseClass(this); } virtual slot clearBuffers() { // Clears the buffer for this instance } }
Then when I want to clear ALL buffers, I just need to
emit clearBuffers
from theBaseClassController
Obviously, the singleton here isn't thread-safe but would this be an obvious way to achieve what I want or is there a much better solution or a more out-the-box solution to this? Or am I barking completely up the wrong tree?
Thanks
@webzoid I agree with @jsulm the aproach makes sense, and its the way I'm doing it in my current project as well.
PS: TO all those native speakers, is "That makes sense" a valid idiom? I always thought it was just a bad translation from my language, but I'm hearing it more and more in all kinds of media.
-
I'm interested in finding from others how you have solved a pretty simple problem.
I have many
QObjects
andQWidgets
. Each of these has a data buffer, varying in type depending on what information it is to hold. All data comes from a single repository but specific data gets farmed out to theseQObjects
andQWidgets
.At certain points in time, I want to clear all buffers from all objects pseudo-instantaneously.
I've thought about having a base class similar to the following pseudo-code:
class BaseClassController { function registerBaseClass(BaseClass *obj) { connect(this, SIGNAL(clearBuffers()), obj, SLOT(clearBuffers()); } private BaseClassController() { } static BaseClassController& instance() { static BaseClassController *inst = nullptr; if (!inst) inst = new BaseClassController(); return *inst; } signal clearBuffers(); } class BaseClass { BaseClass() { BaseClassController::instance().registerBaseClass(this); } virtual slot clearBuffers() { // Clears the buffer for this instance } }
Then when I want to clear ALL buffers, I just need to
emit clearBuffers
from theBaseClassController
Obviously, the singleton here isn't thread-safe but would this be an obvious way to achieve what I want or is there a much better solution or a more out-the-box solution to this? Or am I barking completely up the wrong tree?
Thanks
@webzoid said in Qt Observer-Type Pattern Using Signals and Slots:
At certain points in time, I want to clear all buffers from all objects pseudo-instantaneously.
You really need to have a global variable to do that? What's wrong with propagating a signal to the interested parties? Your code is going to work (provided you fix the concurrency with the singleton), but I question the wisdom of introducing an application-global state ...
Obviously, the singleton here isn't thread-safe but would this be an obvious way to achieve what I want or is there a much better solution or a more out-the-box solution to this?
It's also a memory leak. You could solve both by creating it on the stack, as it's just a utility object that does nothing in its constructor.