Re: Getting struct fields info at runtime?
Robert wrote:
[...] several reasons the position of the fields is a constrain, and when
I add the new fields to the StructVersion2 I can't add them as the last
fields, but I have to add them in particular position, between two
existing fields, so the use of inheritance is non suitable in this
situation.
Why? If the goal is to be byte-by-byte layout-compatible with some external
entity (database BLOB, network packet, device register file) then I would
say that you should treat the different layouts as separate entities. What
I could imagine is that you are using a variant type (e.g. Boost.Variant)
to store the structure:
typedef boost::variant<data_v1, data_v2, data_v3> data_t;
Then, you wrap that in a type that gives you access to the various fields:
struct register_file
{
// only supported by version 2 and 3
uint32_t get_voltage();
private:
data_t m_data;
};
The access is then implemented like this:
uint32_t
register_file::get_voltage()
{
if( data_v2* v2 = variant_cast<data_v2*>(&m_data))
return v2->voltage;
if( data_v3* v3 = variant_cast<data_v3*>(&m_data))
return v3->voltage;
throw std::runtime_error("register_file::get_voltage(): unsupported");
}
[Note: I'm not sure about the variant_cast syntax, but those are
well-documented at Boost's. ]
Summary:
The structures are similar, they are even derived from another, i.e.
represent an evolution, but that does not mean that you can or should try
to model them as related types in C++. I would say that is the wrong
approach. As you see, you can model the common interface at a higher level
still and thus write clear code which doesn't special-case each and every
feature.
Uli