cpp: Store compounds real bit size with its pos

[johannes-wolf]

Please check contribution guide first.

Description

With the implementation of bitPosition(), I did not take relative encoded arrays/packed objects into account. The proposed solution is to store the "physical bit-size" of an object along with its bit-position, because we cannot call bitSizeOf(context, offset) at a later stage.

This PR adds a second field m_realBitSize that stores the physical bit-size of an object on construction.

I am not sure about the name realBitPosition(), maybe physicalSizeOf() or packedSizeOf() is better?

Tests are yet missing. I will add them to this PR.

Type of Change

• Bug fix
• New feature
• Documentation enhancement

[mikir]

Thank you for pointing this out! Packed arrays are indeed a problem.

The naming is always the problem, so I would suggest to implement only one method to return structure with all information:

::zserio::ParsingInfo parsingInfo() const;

struct ParsingInfo
{
    size_t bitPosition;
    size_t bitSize;
};

This will allow to add more parsing information in the future without any change in the design. If this suggestion is ok for you, we will implement it.

But before we do this, I would like to check with you the following:

1. Using the current solution, there is no way how to get the bit position and the bit size of the single field in the compound. Is this ok for your use case?
2. Let's suppose that we will have enough capacity to implement more robust solution. This solution will implement for example read constructor overload which will return hash table which will map Zserio object to Parsing Info. Would it be such solution acceptable for your use case?

[johannes-wolf]

Thank you for pointing this out! Packed arrays are indeed a problem.

The naming is always the problem, so I would suggest to implement only one method to return structure with all information:

::zserio::ParsingInfo parsingInfo() const;

Sounds good! Shall I change that with this PR?

struct ParsingInfo
{
    size_t bitPosition;
    size_t bitSize;
};

This will allow to add more parsing information in the future without any change in the design. If this suggestion is ok for you, we will implement it.

But before we do this, I would like to check with you the following:

1. Using the current solution, there is no way how to get the bit position and the bit size of the single field in the compound. Is this ok for your use case?

Yes, getting the bit-position for non-compound fields is not needed.

2. Let's suppose that we will have enough capacity to implement more robust solution. This solution will implement for example read constructor overload which will return hash table which will map Zserio object to Parsing Info. Would it be such solution acceptable for your use case?

What would be the key used for hashing, and what would be the reason to store the ParsingInfo external to the objects? Memory consumption? I guess such an implementation would work for us.

[mikir]

::zserio::ParsingInfo parsingInfo() const;

Sounds good! Shall I change that with this PR?

Thanks a lot but it is ok, we will do it.

2. Let's suppose that we will have enough capacity to implement more robust solution. This solution will implement for example read constructor overload which will return hash table which will map Zserio object to Parsing Info. Would it be such solution acceptable for your use case?

What would be the key used for hashing, and what would be the reason to store the ParsingInfo external to the objects? Memory consumption? I guess such an implementation would work for us.

The key will be probably the pointer to the Zserio object. The main reason would be to avoid of the possible parsingInfo misuse using the current solution. If we return such hash table only after parsing, there will no way how to call it wrongly (for example, if you create Zserio object manually without calling of read constructor and call bitPosition, you will get wrong results). My idea is that if turns out in the future that this feature is important and should be part of the stable API, we might change the design in this way if it is acceptable for you (no big changes on your side).