Best way to design a simulation class?

[d_stranz]

When I have been faced with a similar issue, I have generally chosen the 2nd architecture. We have a large C++ library of methods for scientific computations, some of which can take time and need to communicate status back to the controller so it can post a progress bar, allow for aborting the operation, etc. This library is used in Qt apps, MFC apps, and headless apps on embedded linux systems so it is vanilla C++.

In most cases, the computation (simulation, in your case) has a set of well-defined callbacks for which the controller can supply pointers to callback functions. At appropriate points in the simulation loop, the simulation will invoke the callback if a pointer has been supplied.

To interface this to the Qt world, I construct a Facade which maps the callbacks into Qt signals and translates C++ types into Qt types (e.g. std::wstring -> QString) if desired. Translation gives the option of using simulation-specific objects to talk to the facade class, but these can be hidden behind the "facade" (hence the name of the design pattern). The facade class could be a GUI, or simply be a QObject for use by other Qt objects. This gives some ability to disconnect the Qt world from the simulation world - the Qt class could have a "stop" button that simply sets a flag in the facade class. Next time the simulation asks, "OK to keep going?", the facade supplies the value of the flag.

Note that in the main application, unless you put the simulation into its own thread, you will still have to service the event loop (i.e. call processEvents()) in order to keep the GUI "live". The facade class can do this for you by calling processEvents() in each callback function, but unless the callback is invoked frequently, the GUI will be doggy.

[Yes]

That's the way I have taken until now. Except I have no facade for my simulation class, but just a function pointer directly in the simulation class that is called whenever the application should process its events.

It was when I had to print output from the simulation into a text browser I have in my main window that I ran into problems. Since the text browser is a member of the window class, I can't access it from any function I can access from the simulation class.

I guess a facade will do the job. If I have a facade class for the simulation class, I can derive another class from it in my Qt application, which in turn contains a pointer to the window object. In the simulation class, I store a pointer to a facade object in which I call a virtual function whenever I want to provide the application with output. If the derived facade wants to write to the text browser, it will simply use the window pointer and access the text browser that way. Nice.

Thank you for the help. A facade it will be!

P.S. I like vanilla

Edit: Forget what I said about a virtual function, I just realized that it can't make up for the hidden argument corresponding to the this pointer that has to be provided if it's supposed to be able to access non-static members...

Edit 2: Never mind, I realized it's not the virtual function that is supposed to make up for the this pointer, but the pointer to the facade object that is stored in the simulation class ... a brain fart. :P

[d_stranz]

In the simulation class, I store a pointer to a facade object in which I call a virtual function whenever I want to provide the application with output.

Actually, I would try to make it more generic than this. The simulation class doesn't really need to know about external classes; it simply needs callback function pointers. These could all belong to the same facade class, could be multiple classes, could be standalone C++ functions, could be function objects (each of which implements a single callback method). The simulation shouldn't know or care, if you want to make things as decoupled as possible.

But if you have control over both ends of the code (simulation and controller), you can make whatever level of dependence you want. If you are interfacing to a third-party library where you have no ability to change the simulation code, then you are forced to decouple in one of the ways above.

[Yes]

Okay, let's assume that we are using a third party library and can only provide it with a function pointer for each callback. What would such a callback function look like if it needs to access an object that can't be accessed globally?

[d_stranz]

What would such a callback function look like if it needs to access an object that can't be accessed globally?

Once upon a time I solved this problem, but I can't remember at the moment. Something to do with a function object class that stored a pointer to another class, but the mapping from a static method (the callback) to a non-static member escapes me.

[Yes]

And you didn't use a singleton?

[Yes]

I took a look at an SDL function (SDL_AddTimer) that has to be provided with a callback function, and apparently it takes an extra parameter except from the function pointer, and that parameter is a void pointer. This extra argument is probably intended to be used (if necessary) as a pointer to an object in order to make it possible for the callback function work with more than just static member variables. You can at least bake in as much information as you possibly want into this pointer since it can point to any kind of object.

Now, SDL is written in C, and I don't know if there is any better way to do this in if you use C++, but at least this is one way in which it can be done.

Edit: Apparently, this way isn't typesafe, which is explained pretty nicely here. That is why the concept of a slot is introduced, which is already a part of Qt. I started to wonder if there is any way to use Qt to make a slot in some way, which I can then pass to my simulation class in order to make the programming typesafe?

[ChrisW67]

If you are going down a non-Qt callback route then you should look at the Boost bind library. Call free functions, static members, member functions, flexible argument handling etc.

[Yes]

I'm sure Boost bind is great; I have previously been looking at a few other Boost classes and even worked with one of them, and they all seem to be really useful. It's just that – if Boost is used in a project, it becomes yet another large library that you need to have installed on your every computer you want to compile the project on... It seems unnecessarily large if you are only going to use one of its classes in your project, why I would rather use some other signal/slot library instead, like sigslot or libsigc++ (although I have never used these two in particular before), that doesn't take up so much space on you hard disc. Or is there some way to download only the header and source files needed for Boost bind and use them in your project?

[ChrisW67]

Boost bind is header only. No extra library needs to be shipped with your program. If you want to avoid Boost then look at how much of TR1 is implemented by your compiler: std::tr1:: function and bind.