There is minimal size penalty from this, and it is probably much more
intuitive to use than PB_OSTREAM_SIZING itself.
This has been suggested before also, but I ended up refusing it back
them. Reconsidering it now, I see that an intuitive API is much better
than any amount of documentation explaining a non-intuitive API.
Update issue 16
Status: FixedInGit
return pb_encode_submessage(stream, fields, src_struct);
}
+bool pb_get_encoded_size(size_t *size, const pb_field_t fields[], const void *src_struct)
+{
+ pb_ostream_t stream = PB_OSTREAM_SIZING;
+
+ if (!pb_encode(&stream, fields, src_struct))
+ return false;
+
+ *size = stream.bytes_written;
+ return true;
+}
+
/********************
* Helper functions *
********************/
*/
bool pb_encode_delimited(pb_ostream_t *stream, const pb_field_t fields[], const void *src_struct);
+/* Encode the message to get the size of the encoded data, but do not store
+ * the data. */
+bool pb_get_encoded_size(size_t *size, const pb_field_t fields[], const void *src_struct);
+
/**************************************
* Functions for manipulating streams *
**************************************/
TEST(WRITES(pb_encode_delimited(&s, IntegerContainer_fields, &msg),
"\x09\x0A\x07\x0A\x05\x01\x02\x03\x04\x05"))
}
+
+ {
+ IntegerContainer msg = {{5, {1,2,3,4,5}}};
+ size_t size;
+
+ COMMENT("Test pb_get_encoded_size.")
+ TEST(pb_get_encoded_size(&size, IntegerContainer_fields, &msg) &&
+ size == 9);
+ }
{
uint8_t buffer[10];