|
1 | 1 | # xplugin |
| 2 | + |
| 3 | +[](https://github.com/QuantStack/xplugin/actions/workflows/ci.yaml) |
| 4 | + |
2 | 5 | Generic plugin framework in C++. |
3 | 6 |
|
4 | 7 | ## Features |
5 | 8 |
|
6 | 9 | - [x] Generic plugin framework |
7 | | -- [x] Abitrary abstract base classes can be used as plugin interface |
| 10 | +- [x] Arbitrary abstract base classes can be used as plugin interface |
8 | 11 | - [x] Customizable with custom plugin factories (see examples) |
9 | | -- [x] Works on Linux, Mac and Windows and emscripten |
| 12 | +- [x] Works on linux, mac, windows and emscripten |
10 | 13 |
|
11 | 14 | ## Usage |
12 | 15 |
|
13 | 16 | ## Example 1 |
14 | 17 |
|
15 | | -All plugins are derived from a a base class, in the first example `MyPluginBase`. |
| 18 | +All plugins are derived from a base class, in the first example `MyPluginBase`. |
16 | 19 | All concrete plugins are derived from `MyPluginBase` and implement the pure virtual function (in this example it is only the `do_something()` function). |
17 | 20 | Furthermore, for this example, we assume that all concrete plugins have an empty constructor. |
18 | 21 | (see example 2 for a more complex example) |
@@ -114,7 +117,7 @@ int main(int argc, char** argv) |
114 | 117 |
|
115 | 118 | We again define a plugin interface `MyOtherPluginBase` and a concrete plugin implementations `MyOtherPluginA` and `MyOtherPluginB`. |
116 | 119 | The difference to the first example is that the concrete plugins have a constructor with arguments. |
117 | | -But both plugins have the same constructor signature. (see example 3 for a more complex example) |
| 120 | +But both plugins have the same constructor signature. |
118 | 121 |
|
119 | 122 | `my_other_plugin_base.hpp`: |
120 | 123 | ```cpp |
|
0 commit comments