I have seen a common need where code has to compute a struct size outside of emboss to properly allocate that space. It then applies an emboss view on that allocated space.
For non-dynamically-sized structs the code can use static IntrinsicSizeInBytes to get the needed size. But for dynamically-sized structs (that determine size based on parameters or fields) the code usually has to do its own computation of struct size outside of emboss.
I have been thinking that for dynamically-sized structs where parameters are enough to determine the size, it would be handy if emboss generated a parameterized version of the static IntrinsicSizeInBytes function that can take the struct's parameters and use them to compute the size.
So
struct Bar(x: UInt:8, y: Int:32)
would generate something like
template <typename T>
auto MakeBarView(std::uint8_t x, std::int32_t y, T *data, size_t size);
and also generate the new
static constexpr auto IntrinsicSizeInBytes(std::uint8_t x, std::int32_t y) const;
Above assumes the parameters are enough to compute the size. If not, then no IntrinsicSizeInBytes would be created. I think recognizing these cases is probably one of the trickt parts of any implementation.
I have seen a common need where code has to compute a struct size outside of emboss to properly allocate that space. It then applies an emboss view on that allocated space.
For non-dynamically-sized structs the code can use static
IntrinsicSizeInBytesto get the needed size. But for dynamically-sized structs (that determine size based on parameters or fields) the code usually has to do its own computation of struct size outside of emboss.I have been thinking that for dynamically-sized structs where parameters are enough to determine the size, it would be handy if emboss generated a parameterized version of the static
IntrinsicSizeInBytesfunction that can take the struct's parameters and use them to compute the size.So
would generate something like
and also generate the new
Above assumes the parameters are enough to compute the size. If not, then no IntrinsicSizeInBytes would be created. I think recognizing these cases is probably one of the trickt parts of any implementation.