-
Notifications
You must be signed in to change notification settings - Fork 26
Native Run-Time Type Information support #169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
An attempt to avoid increased memory consumption of MSVC compiler.
Member
|
Now covered by #182 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is based on #141 and #142
PR is in draft state so far but fully illustrate an approach that allows using native RTTI support.
In a few words the PR addresses missed part of ACT - original type of an object that has been passed from library to application side.
Let's look on an example.


AnimalIteratorclass has a methodGetNextAnimal()method that returns instance ofAnimal.But in fact, actual object could be any of derived animal classes.
So the signature of the method is defined. And this is what ACT generates today:
It creates shared pointer to an instance of
Animalclass. Just like defined in IDL file.However, this is not what actually happens under the hood. Animal objects on library side belong to other classes.
This information just gets lost through ACT because it passes objects as a typeless handle.
IMHO, ideally, class type should be just a part of Handle type. Instead of
void *it could be a struct with two fields:void*and aclassId.But in this PR for a simplicity of reviewing the idea I leave handle as
void *and just add class type id.Each class has unique Class Type Id in a form of 64 bits unsigned integer. It's generated as 64 most significant bits of SHA1 for a string
NameSpace::ClassName, whereNameSpaceis a namespace defined in IDL file andClassNameis an actual name of a given class.Base class has a virtual method
uint64 ClassIdType(). In C++ implementation it belongs to interfaces layer and thus completely hidden from developers.Actual name is configured in IDL by global setting
classtypeidmethod. It's autogenerated by ACT and returns class type id.On a bindings side (application) ACT implements hidden from developer
PolymorphicFactory()function that is used to instantiate objects from handle. Instead ofstd::make_sharedon C++, for example.It serves only one goal - instantiate correct class on an application side that matches class of a handle on a library side.
C++ example:
and then used instead of
std::make_sharedin class method implementation forclassparameters passed asoutorreturn.I already mentioned above that direct call to
ClassTypeId()method to retrieve object class is not optimal and could be optimized.It's better passing class type with a handle. Either as part of Handle type or by extra parameter of a C function call.
This PR includes implementation for C++, Python and Pascal bindings and C++ with Pascal Stubs.
On an application side code relies on a language native capabilities:
C++
Python
Pascal:
NOTES and TODO: