Use Boost.TypeIndex CTTI to implement type info when RTTI is not enabled #12
Conversation
| @@ -11,11 +11,13 @@ | |||
| #include <boost/assert.hpp> | |||
| #include <boost/config.hpp> // BOOST_MSVC | |||
| #include <boost/detail/workaround.hpp> | |||
| #if !defined(BOOST_STATECHART_USE_NATIVE_RTTI) | |||
There was a problem hiding this comment.
Do we need to worry about BOOST_NO_RTTI here?
Is this macro new? - does it need documentation and additional test cases?
There was a problem hiding this comment.
This is to avoid including Boost.TypeIndex when not needed. The macro is not new, it is already documented and is tested by *Native tests.
|
If you think the combination of this and #10 solve the build issues, rebase this to test that. |
…led. This allows to solve the problem with comparing addresses of global id_provider objects, which fail if the objects reside in different modules. Boost.TypeIndex solves this problem by comparing specially crafted strings, which are equal if the respective types are the same. Unfortunately, this will likely result in a performance drop as string comparison is likely more expensive than comparing pointers. Any performance optimizations are better placed in Boost.TypeIndex.
Lastique
force-pushed
the
port_to_type_index
branch
from
4bbcf67 to
76699e5
Compare
Done. |
|
Looks like we have one build still failing, the OSX one. Is the failure related or environmental? It looks like it is a unit test failure. I'm going to rekick it once to see if it is transient. Here's the job that failed: |
I don't know, I don't have OS X to investigate. |
|
That's a very unusual way to use Boost.TypeIndex library. Initially it was designed to hide all the typeid related workarounds under the hood and deal with the symbol visibilities/rtti in different shared objects. So in my head the PR should drop all the This will shorten the code and provide the most efficient way for typeid comparisons. |
|
The reason I did it the way I did is because |
This allows to solve the problem with comparing addresses of global id_provider
objects, which fail if the objects reside in different modules. Boost.TypeIndex
solves this problem by comparing specially crafted strings, which are equal
if the respective types are the same.
Unfortunately, this will likely result in a performance drop as string
comparison is likely more expensive than comparing pointers. Any performance
optimizations are better placed in Boost.TypeIndex.
This is the next step after fixing the build in #10. I'm posting it as a separate PR as this change is more controversial.
Relates to and fixes #9.