Boost: signals2 Learning

Write by nine days Yan Ling (jtianling) -- blog.csdn.net/vagrxie

Discuss newsgroups and documents

Signal and slot systems are the key part I want to use to decouple various modules in the game engine. Although I have written some simple implementations before, I cannot find the original code today, and now I am getting lazy ..... So, let's learn about the signal2 library in boost .......... In shame. After I found that the Loki library was used in a relatively successful project in the company, it became more and more bold to use the external library ..... What's more, this is just my own work. It's not too much to use boost on demand .... Well, it's not a problem.

Why do we need signals and slots? Imagine that QT is almost built on this basis and can be understood so easily. Reducing coupling is the core purpose.
Signals and slots allow each object to process its own tasks. For example, a button can only notify itself that it has been pressed rather than directly processing what should be done after the button is pressed.
The object that needs to respond to the button message should just register what you need to do after the button is pressed, rather than checking whether the button is pressed every time. After all, the round-robin query is far less effective than the notification.
The benefits of the UI signal-slot design are enormous, which makes the object's responsibilities clearer and reduces code coupling. One day, you want to change the response code, OK, no problem, let's change it directly. The UI Layer is the same as the original one. You don't need to care about external changes, and vice versa. This is definitely impossible if you put the operation directly in the place where the button is pressed.

However, I personally think it is special in the game, because each object has a fixed update activity cycle, and each object should be processed in its own update cycle, otherwise, the update sequence may be damaged, resulting in problems. in addition, the loop query problem in common applications can be almost ignored in the game, because the game itself is a loop, no matter what time, the game is at the render frame, each frame is updated, unless you are willing to show players a static game that is usually full. In addition, it is important to note that in any case, such flexibility does not have to be cost-effective, just as dynamic languages tend to be easier to use than static languages, at the cost of performance, the signal and slot also have an indirect layer in the best case.

The following example (from the boost document) is the most valuable and can be used to illustrate the problem. The solution is the one I mentioned.

// [Passing_slots_defs_code_snippet
// A pretend GUI button
Class button
{
Typedef boost: signals2: signalvoid (int x, int y)> onclick;
Public:
Typedef onclick: slot_type onclickslottype;
// Forward slots through button interface to its private signal
Boost: signals2: Connection doonclick (const onclickslottype & slot );

// Simulate user clicking on GUI button at coordinates 52, 38
Void simulateclick ();
PRIVATE:
Onclick;
};

Boost: signals2: Connection button: doonclick (const onclickslottype & slot)
{
Return onclick. Connect (slot );
}

Void button: simulateclick ()
{
Onclick (52, 38 );
}

Void printcoordinates (long X, long y)
{
STD: cout "(" "," ") N ";
}
//]

Int main ()
{
// [Passing_slots_usage_code_snippet
Button button;
Button. doonclick (& printcoordinates );
Button. simulateclick ();
//]
Return 0;
}

Refer:
"Boost manual, signal2". I am very grateful to Jin Qing for translating it into Chinese, and the translation is very good.

 

The author of the original article retains the copyright reprinted. Please indicate the original author and give a link

Write by nine days Yan Ling (jtianling) -- blog.csdn.net/vagrxie