The current handling of qHostInfo is a bunch of if-else,
one for each key we think we might find. This works fine,
but we end up repeating parsing calls and extending it
gets tricky.
To improve this I'm adding KeyValueExtractorGDBRemote.
This is a class that takes the packet response and splits it up
into the key-value pairs. Where a pair is "<key>:<value>;".
Then you can do Get<T>(<key>) to get an Optional<T>.
This Optional is empty if the key was missing or its value
didn't parse as the T you asked for.
Or you can GetWithDefault<T>(<key>, <default value>)
which always gives you a T but if search/parse fails
then you get <default value>.
Plus specific methods to get LazyBool and hex encoded
string keys.
This improves the packet handling code by:
- Putting the type, key name and default value on the same line.
- Reducing the number of repeated parsing calls. (fewer "!value.getAsInteger(0, ...)" means fewer chances to forget a "!")
- Removing the need for num_keys_decoded, which was essentially a boolean but was treated as a running total. (replaced with HadValidKey)
We do pay an up front cost in building the map of keys up
front. However these packets are infrequent and the increase
in readability makes up for it.
This change adds the class and applies it to qHostInfo, keeping
the original logic intact. (future patches will apply it to
other packets and refactor post decode logic)
clang-format not found in user's PATH; not linting file.