Conditional deserialization

Question

I am still not sure whether the title of my question is correct and it most probably is not. However I have spent some time searching both the net and stackoverflow and I can not find a good description of the issue I am facing.

Basically what I want to achieve is the ability to read some raw bytes and based on the value of some of them to interpret the rest in different ways. This is how TLV works in a way, you check the tag and depending on it - interpret the result. Of course I can always keep that logic in my C++ code, however I am looking for a solution which would move the logic out of the source code (maybe to some xml description). This would allow me to describe different encodings (protocols) more easily. I am familiar with Protocol Buffers and some other serialization libraries, however all of them solve different issue. They assume they are on both ends of the communication, while I want to describe the communication (sort of).

Is such solution available, if no - why not? Are there some inherent difficulties I will face trying to implement it.

Answer 1

I know of nothing like this.

As to why there isn't anything it probably comes down to nobody really needs it. A communications protocol is unlikely to change in any significant way so why pay for the ability to react to changes that won't occur?

Answer 2

I believe this is an easy task, a lot of work, but easy.

Two important concepts: 1) Factories and 2) Object controls deserialization. The factories will create an object instance based on an ID or tag. Once the object is created, the object is responsible for loading its members from a data stream (or buffer).

A simpler design may be to implement nested factories. A factory calls a sub-factory based on an ID. This may continue down a chain until a final static creation method is called to create the appropriate object instance.

The final object would be passed the stream (or buffer) and it would load its data members. The reason for having the object load its members (rather than an external object or function) is that the object knows the types and layouts of its members. Also, one location for everything, so that when an data member is added or removed, only the object changes, not other external functions (that access the objects data members).

Hope this helps.