I have a Qt window application that runs a simulation which should be "unknowing" about any details of the application. That is, it shouldn't have any idea whether it's communicating with a Qt application, any other type of application, or if it's just communicating with a wall. The simulation class should be stand-alone from the rest of the application and should be easily plugged in to any other application. However, it should also be able to provide the application with any information it could possibly need – for example information to the user. It should also not block the application from doing other things it may need to do.
My question is: How is this simulation class best designed? Is there some standard way to do this when writing Qt applications (or any other kind of toolkit application for that matter)?
I see basically three different ways in which the simulation class can be designed:
- The simulation has it's own main loop but is created in a separate thread, and the main thread that still maintains the application keeps querying the simulation for events that has happened, for example things the user should be informed of.
.- No separate thread is created for the simulation, but the simulation "hijacks" the application until it has finished. When the simulation for some reason needs to communicate back to the application, for example to just let it process its events, a function pointer relevant to the task is called and the application is free to do whatever it needs to do.
.- The simulation doesn't have a main loop at all, but relies on to continuously be prompted by the application to do more and more loops of the simulation. Between the simulation loops, the application is free to do whatever it wants to do.
I see benefits and drawbacks with all these different ways.
Way 1 is quite easy to understand and doesn't need to be designed in any specifically complicated way. On the other hand, the thread the simulation is running in has to compete with another thread for CPU power and will hence run more slowly (right?).
In way 2, the simulation is provided with function pointers which it calls whenever it wants to communicate back to the application. It now gets a responsibility to call these functions in the right moments. It is also tricky to design these functions in the right way. For example, the function pointers must not point to non-static member functions, since they have a hidden parameter corresponding to the this pointer which the simulation class is not provided with. This can be problematic if the application wishes to write output data in a text browser in the main window, since the text browser is probably a non-static member of the window and must be accessed from a non-static member function, unless the function is provided with some additional information about where to find the text browser object.
Now, there will probably only be one instance of the main window, so it would be possible to create it as a singleton making it possible to access the non-static members from a static member function, but that should be up to the designer of the application.
In way 3, the application gets full control of the simulation, it can for example pause the simulation whenever it wants to by just ceasing to call it for a while. The only problem here is that the simulation mustn't do any loop that is longer than, say, a tenth of a second, because that would create noticeable lagging in the application. This makes it very challenging to program longer operations, such as writing a large amount of data to a file, since they have to be divided into small steps which are then executed one at a time from a public function.
Alternatively, this method can be combined with way 2 in order to not have to divide all operations into small steps, but that kind of removes the purpose of dividing all other long operations into small steps to begin with since we're back struggling with the functions and the function pointers.
I would be grateful for any comments on these ideas. Are they right or wrong? How would you have done this?
Bookmarks