|
|
@@ -19,9 +19,8 @@
|
|
|
general and on GNU/Linux when default visibility was set to hidden. The
|
|
|
limitation was mainly due to a custom utility used to assign unique, sequential
|
|
|
identifiers with different types.<br/>
|
|
|
-Fortunately, nowadays using `EnTT` across boundaries is straightforward. In
|
|
|
-fact, everything just works transparently in almost all cases. There are only a
|
|
|
-few exceptions, easy to deal with anyway.
|
|
|
+Fortunately, nowadays using `EnTT` across boundaries is easier. However, use in
|
|
|
+standalone applications is favored and user intervention is otherwise required.
|
|
|
|
|
|
## The EnTT way
|
|
|
|
|
|
@@ -50,25 +49,17 @@ In general, these classes don't arouse much interest. The only exceptions are:
|
|
|
* When working with plugins or shared libraries that don't export any symbol. In
|
|
|
this case, `type_index` confuses the other classes by giving potentially wrong
|
|
|
information to them.<br/>
|
|
|
- To avoid problems, it's required to provide a custom generator or to suppress
|
|
|
- the index generation as a whole:
|
|
|
-
|
|
|
- ```cpp
|
|
|
- template<typename Type>
|
|
|
- struct entt::type_index<Type> {};
|
|
|
- ```
|
|
|
-
|
|
|
- All classes that use `type_index` perform also a check on the possibility of
|
|
|
- creating indexes for types. If it's not a viable solution, they fallback on
|
|
|
- the type id provided by `type_info`. The latter makes everything stable across
|
|
|
- boundaries.<br/>
|
|
|
- This is why suppressing the generation of the indexes solves the problem. In
|
|
|
- case it's still necessary to associate sequential indexes with types, users
|
|
|
- can refer to the `family` class, although knowing that these will not be
|
|
|
- stable across boundaries.
|
|
|
+ To avoid problems, it's required to provide a custom generator. Briefly, it's
|
|
|
+ necessary to specialize the `type_index` class and make it point to a context
|
|
|
+ that is also shared between the main application and the dynamically loaded
|
|
|
+ libraries or plugins.<br/>
|
|
|
+ This will make the type system shared and available to the whole application,
|
|
|
+ not just to a particular tool such as the registry or the dispatcher. It means
|
|
|
+ that a call to `type_index::id()` will return the same identifier for the same
|
|
|
+ type from both sides of a boundary and can be used reliably for any purpose.
|
|
|
|
|
|
For anyone who needs more details, the test suite contains multiple examples
|
|
|
-covering the most common cases.<br/>
|
|
|
+covering the most common cases (see the `lib` directory for all details).<br/>
|
|
|
It goes without saying that it's impossible to cover all the possible cases.
|
|
|
However, what is offered should hopefully serve as a basis for all of them.
|
|
|
|
|
|
@@ -76,8 +67,8 @@ However, what is offered should hopefully serve as a basis for all of them.
|
|
|
|
|
|
The runtime reflection system deserves a special mention when it comes to using
|
|
|
it across boundaries.<br/>
|
|
|
-Since it's linked to a static context to which the visible components are
|
|
|
-attached and different contexts don't relate to each other, they must be
|
|
|
+Since it's linked already to a static context to which the visible components
|
|
|
+are attached and different contexts don't relate to each other, they must be
|
|
|
_shared_ to allow the use of meta types across boundaries.
|
|
|
|
|
|
Sharing a context is trivial though. First of all, the local one must be
|