-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add size_bytes()
for message/group/data traits
#43
Conversation
Eventually would be great to add an example to the documentation of how this function is used in the message sending flow. |
Makes sense, will add it to this PR later. |
Added more tests and found a bug, making it a draft for now. |
Fixed, ready to be merged. |
Perfect, it works like a charm. The only minor issue is that the code of the |
Improved parameter list formatting, now it's a parameter per line, not a single giant line. Don't see much reason to care about function body formatting because users are not supposed to read it (when I need to do this, I just open a header and apply clang-format to it). |
Implements functionality discussed in #33.
Here's a brief overview of considered design options.
sbepp::predict_size_bytes<T>(args...)
whereT
is a representation type (e.g.schema_name::messages::msg_name
). While it was the initial choice, further investigation discovered multiple issues with this approach:static
function of representation type because it's not related to its functionality, it doesn't need anything from it, nor it provides anything to it.Since it's static in nature, potential implementation of
sbepp::predict_size_bytes<T>
would require an internalstruct
withstatic
function and its specializations for each representation type. At this point this looks much more like a trait so the following approach was chosen.message_traits<Tag>::size_bytes(args...)
. Traits are already used to provide static/meta information, for examplecomposite_traits::size_bytes()
so after a bit of thinking, this looked like a natural way to go. While it's unlikely that someone will ever needgroup_traits::size_bytes()
ordata_traits::size_bytes()
, they are used internally formessage_size::size_bytes()
so I see no reason to keep them private. Unlikesbepp::predict_size_bytes()
, this approach allows user to see all the parameters which is definitely a benefit since they depend on the message structure. While using trait might be a bit verbose, #41 should make it possible to get trait tag from representation type to avoid using both types in code.