Skip to content
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

Improve reflection system and static_variant #156

Merged
merged 3 commits into from Sep 1, 2019

Conversation

nathanielhourt
Copy link

@nathanielhourt nathanielhourt commented Aug 29, 2019

Previously, fc reflection generated visitor infrastructure capable of
visiting each field of a struct; however, this is only useful for run-
time operations on structures. No compile-time information was preserved
about the fields of a struct, making compile-time introspection of types
impossible.

Now FC reflection generates rich compile-time information about the
members of structs, including types, names, and structure, allowing
code to be written to explore types in detail at compile-time and fetch
arbitrary fields at runtime without needing to iterate over the unwanted
fields.

To make this a reality, a new typelist type was added to store this
compile-time information. This type is also useful within the context of
static_variant, as SV previously used implementation detail types in a
private namespace to provide equivalent functionality. Now static_variant
uses the reusable functionality of typelist to operate, dramatically
reducing the amount of code dedicated to static_variant and also
making static_variant types more flexible to work with since their
infrastructure is now based on the typelist public interface.

These changes are necessary for bitshares/bitshares-core#1860

include/fc/reflect/reflect.hpp Outdated Show resolved Hide resolved
include/fc/static_variant.hpp Outdated Show resolved Hide resolved
include/fc/static_variant.hpp Outdated Show resolved Hide resolved
pmconrad
pmconrad previously approved these changes Aug 30, 2019
Copy link

@pmconrad pmconrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you make this look so simple! Excellent work! :-)
@abitmore?

Previously, fc reflection generated visitor infrastructure capable of
visiting each field of a struct; however, this is only useful for run-
time operations on structures. No compile-time information was preserved
about the fields of a struct, making compile-time introspection of types
impossible.

Now FC reflection generates rich compile-time information about the
members of structs, including types, names, and structure, allowing
code to be written to explore types in detail at compile-time and fetch
arbitrary fields at runtime without needing to iterate over the unwanted
fields.

To make this a reality, a new `typelist` type was added to store this
compile-time information. This type is also useful within the context of
`static_variant`, as SV previously used implementation detail types in a
private namespace to provide this functionality. Now `static_variant`
uses the reusable functionality of `typelist` to operate, dramatically
reducing the amount of code dedicated to `static_variant` and also
making `static_variant` types more flexible to work with since their
infrastructure is now based on the `typelist` public interface.
@abitmore
Copy link
Member

@pmconrad I haven't fixed the TRAVIS_BUILD issue yet, it does not only affect Travis though.

@nathanielhourt
Copy link
Author

nathanielhourt commented Aug 30, 2019

Ah, you make this look so simple! Excellent work! :-)

Thank you very much, Peter =) That means a great deal to me.

@nathanielhourt
Copy link
Author

nathanielhourt commented Aug 30, 2019

Shiny new static_variant::operator== in a75fcb5

I'm opting to leave out a default operator< as it's not immediately obvious how to resolve comparison between unmatched types. Not to mention, our flat_set usages depend on the fact that (static_variant<int>(1) < static_variant<int>(2)) == false. type_lt gets us that, but it's dangerous to add a default operator< in light of this fact.

@pmconrad
Copy link

pmconrad commented Aug 31, 2019

Please rebase -i and fixup the travis workaround removal.

@nathanielhourt
Copy link
Author

Done

Copy link

@pmconrad pmconrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fixup went into the wrong commit, but nevermind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants