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

Adding MPark's variant (V1.4.0) to HPX #4038

Closed
wants to merge 1 commit into from
Closed

Conversation

hkaiser
Copy link
Member

@hkaiser hkaiser commented Aug 25, 2019

This PR adds MPark's implementation of std::variant (https://github.com/mpark/variant) to HPX' datastructures module.

  • adding serialization support for hpx::util::variant
  • flyby: add support for skipping whole files to inspect (without modifying them)

This is in preparation of moving boost::program_options to HPX (see #3440)

- adding serialization support for hpx::util::variant
- flyby: add support for skipping whole files to inspect (without modifying them)
@hkaiser
Copy link
Member Author

hkaiser commented Aug 26, 2019

Actually, we don't need variant for program_options, just optional and any. It's probably fine to close this without merging...

@msimberg
Copy link
Contributor

Actually, we don't need variant for program_options, just optional and any. It's probably fine to close this without merging...

We do use variant, even though it's in only one place (parse_affinity_options) so it probably wouldn't hurt to have this in for that. In any case, the serialization test and inspect changes are useful as well.

@hkaiser
Copy link
Member Author

hkaiser commented Aug 26, 2019

@msimberg: we will have to wait for @mpark to disable the warning/error generated by the variant header (see mpark/variant#68). Alternatively, we could disable this diagnostic in our build system (for now).

@hkaiser
Copy link
Member Author

hkaiser commented Aug 26, 2019

We do use variant, even though it's in only one place (parse_affinity_options) so it probably wouldn't hurt to have this in for that. In any case, the serialization test and inspect changes are useful as well.

@msimberg: isn't variant used only in the context of the Spirit parser? In this case replacing it would be feasible but not absolutely necessary.

@msimberg
Copy link
Contributor

Yes, only for the parser. And if spirit is optional, so is variant... Good point! And do we actually need the variant serialization? Maybe you're right that we should just close this without merging.

@hkaiser
Copy link
Member Author

hkaiser commented Aug 27, 2019

Closing this without merging (for now).

@hkaiser hkaiser closed this Aug 27, 2019
@hkaiser hkaiser deleted the adding_variant branch August 27, 2019 11:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants