What is the best data structure for storing FIX messages?

Question

What is the best way to store the next message in a data structure for easy access?

"A = a bc, B = 156, M = 3, G = 1, H = 10, G = 2, H = 20, G = 3, H = 30, X = 23.50, Y = XYZ"

The above consists of key / value pairs of the following values:

A = a
B = 156
F = 3
G = 1
H = 10
G = 2
H = 20
G = 3
H = 30
X = 23.50
Y = Hug

The hard part is the keys F, G, and H. F indicates the number of elements in the group whose element consists of G and H.

For example, if F = 3, there are three elements in this group: Point 1: G = 1, H = 10 Point 2: G = 2, H = 20 Point 3: G = 3, H = 30

In the above example, each element consists of two key / pair values: G and H. I would like the data structure to be flexible so that it can handle if the element increases its key / pair values. As much as possible, I would like to maintain the order that it appears in the row.

UPDATE: I would like to save key / value pairs as strings, even if the value often appears as a float or other data type, such as a map.

Answer 1

It may not be what you are looking for, but I would just recommend using QuickFIX (quickfixengine.org), which is a very high-quality C ++ FIX library. I think it has a type of "FIX :: Message" that does whatever you are looking for.

Answer 2

I work a lot with FIX in Python Perl, and I tend to use a dictionary or hash. Your keys must be unique in the message. For C ++, you can look at std :: map or the STL extension std :: hash_map.

Answer 3

If you have a subset of the FIX messages you need to support (most exchanges typically use 10-20 types), you can fold your own classes to parse the messages. If you are trying to be more general, I would suggest creating something like a FIXChunk class. All message text can be stored in this class, organized into keys and their values, as well as lists of repeating groups. Each of the repeating groups would itself be FIXChunk.

Answer 4

A simple solution, but you can use std::multimap<std::string,std::string> to store data. This allows you to have multiple keys with the same value.

Answer 5

In my experience, message corrections are usually stored either in their original form (as a stream of bytes) or as a complex data structure that provides complete APIs that can cope with their complexities. After all, a fix message can sometimes represent a data tree.

The problem with the latter solution is that the transition is expensive in terms of the cost of computing in high-speed trading systems. If you are building a trading system, you can count on the lazy calculation of the parts of the commit message than you need, which is admittedly easier said than done.

I am not familiar with efficient open source implementations; companies like me usually have their own implementations.