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

Usability with msg::disjoint_field #319

Closed
herculanodavi opened this issue Jul 12, 2023 · 1 comment
Closed

Usability with msg::disjoint_field #319

herculanodavi opened this issue Jul 12, 2023 · 1 comment

Comments

@herculanodavi
Copy link
Contributor

The msg::disjoint_field is very useful to me, but I'm going through the problems below and would be happy to make a PR with these changes:

Add access to the DWordIndex of the contained types

When making a message that uses only msg::field (and no msg::disjoint_field), it is normally easy to calculate the necessary message size, since it should be 1 + std::max({FieldsT::DWordIndex...}) (considering we start always from zero), when FieldsT is the template parameter pack of the message fields.

It's not easy, though, to perform this when using messages with msg::disjoint_field because the inner fields are not provided as a type alias and the fields variable is private.

Could a public type alias to FieldsT be provided to make this calculation possible? Or maybe a method that returns a list of DWordIndex of every type?

Add ValueType alias

Same situation as 1, but now for making templates that use the ValueType field. It is avaliable in msg::field but not in msg::disjoint_field, even though it is one of the template arguments.

Could a public alias to T, say, using ValueType = T be provided?

@herculanodavi
Copy link
Contributor Author

With the #320 merge, now msg::disjoint_field does not compile when part of a msg::message_base because it has no DWordExtent member. #321 fixes that.

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

No branches or pull requests

1 participant