Merge pull request #1 from hit9/dev

Improve readme

README.md

@@ -6,34 +6,6 @@ blinker.h
 
 A lightweight signal/event library for C++, similar to Python's blinker, but designed to work with ticking loops.
 
-
-## Mechanism and Concepts
-
-1. A signal board contains at most N signals.
-   Where a signal is just composed of an id and name.
-
-2. A signal's name should be delimited by dots, e.g. "movement.arrived".
-
-   Signals are structured into a trie by names in the pre-process stage.
-
-3. A subscriber is just a function.
-   It can connect to one or multiple signals by providing signal names,
-   or prefix patterns e.g. "movement.*".
-
-4. Connections are owned by user, the board doesn't manage them.
-
-5. Each connection has a signature, abstracts as a bitset, of which the n'th bit
-   setting to true means that the signal of id n is subscribed by this connection.
-
-6. Runtime signal dispatching is done by bitset's AND operation, instead of name matching,
-   so it's fast enough. The string matching is only performed at pre-process stage, to generate signatures for connections.
-
-7. Double buffers for a board under the hood:
-   1. The frontend buffer is for subscribers to poll.
-   2. The backend buffer is for new signal emittings.
-   3. The two should be flipped on each tick.
-   4. Each buffer owns a signature of fired signals.
-
 ## Code Example
 
 1. Setup board, signals and connections:
@@ -42,11 +14,11 @@ A lightweight signal/event library for C++, similar to Python's blinker, but des
    // Creates a board.
    blinker::Board board;
 
-   // Creates signals.
+   // Creates signals, returns shared pointers.
    auto ab = board.NewSignal("a.b");
    auto ac = board.NewSignal("a.c");
 
-   // Connects to some signals.
+   // Connects to some signals, returns unique pointers
    auto connection = board.Connect("a.*");
    ```
 
@@ -75,6 +47,34 @@ A lightweight signal/event library for C++, similar to Python's blinker, but des
 
 Also checkout [example/main.cc](example/main.cc).
 
+## Mechanism and Concepts
+
+1. A signal board contains at most N signals.
+   Where a signal is just composed of an id and name.
+
+2. A signal's name should be delimited by dots, e.g. "movement.arrived".
+
+   Signals are structured into a trie by names in the pre-process stage.
+
+3. A subscriber is just a function.
+   It can connect to one or multiple signals by providing signal names,
+   or prefix patterns e.g. "movement.*".
+
+4. Connections are owned by user, the board doesn't manage them.
+
+5. Each connection has a signature, abstracts as a bitset, of which the n'th bit
+   setting to true means that the signal of id n is subscribed by this connection.
+
+6. Runtime signal dispatching is done by bitset's AND operation, instead of name matching,
+   so it's fast enough. The string matching is only performed at pre-process stage, to generate signatures for connections.
+
+7. Double buffers for a board under the hood:
+   1. The frontend buffer is for subscribers to poll.
+   2. The backend buffer is for new signal emittings.
+   3. The two should be flipped on each tick.
+   4. Each buffer owns a signature of fired signals.
+
+
 License
 -------