Message Pack Codec

JSON is easy to read and easy to get wrong at speed: text digits for every number, quotes and escaping for every string, and a parser that has to tokenise before it can do anything. MessagePack encodes the same data as typed binary - a marker byte says what follows, and every integer is stored in the smallest width that holds it. The wire format is smaller, and decoding it is arithmetic on bytes rather than character scanning. This is a streaming codec, not a generic value-tree parser. A decoder that hands back "a value of whatever type was encoded" needs a tagged union or a class hierarchy with virtual dispatch. This codec makes the same call every serious embedded MessagePack implementation makes on either platform: expose WriteX/ReadX functions that the caller sequences to match a message shape known at both ends. Calling WriteMapHeader(5) followed by five key/value pairs is not a workaround here - it is how MessagePack is meant to be driven when a terminal is talking to a service it was written to talk to, which is the only situation this header is for. Two details separate a correct implementation from a plausible-looking one. First, integers: every value is written in the smallest representation that holds it - positive and negative fixint for the common small case, widening through 8/16/32/64-bit forms only when the value needs it. Skipping that and always writing 8 bytes would quietly turn MessagePack back into something the size of JSON. Second, floats: neither MQL4 nor MQL5 has a bit-cast operator to reach a double's raw bytes, so this codec uses StructToCharArray and CharArrayToStruct on both platforms - copying a variable's memory layout verbatim into a byte array and back - which is the standard MQL technique for type punning without an unsafe cast, then reverses the byte order because the wire format is big-endian and x86 is not. SkipValue() lets a reader step over a field it does not recognise, including recursing through nested arrays and maps, so a message can grow new fields on one side of a connection before the other side is redeployed - the same forward-compatibility habit protobuf callers need, for the same reason. Notes and limitations - bin, ext, and float32 are not written by this codec (ReadDouble always expects float64), and PeekType()/SkipValue() report them as unknown if they appear in a buffer this codec did not produce. Messages produced by a DIFFERENT MessagePack implementation that uses those types will not round-trip through this reader. - ReadInt() widens every integer width up to long (64-bit signed). A genuinely unsigned uint64 value above LONG_MAX will read back as a negative long - neither platform has an unsigned 64-bit type to hold it correctly. - Strings are always UTF-8 on the wire, matching the MessagePack specification; MQL strings are UTF-16 internally on both platforms, and the conversion goes through StringToCharArray/CharArrayToString with CP_UTF8 on both. - This is not a validating parser for arbitrary third-party MessagePack data. Feeding it a truncated or corrupted buffer causes Read* calls to return false once they run past the end, but earlier reads on the same corrupted buffer are not guaranteed to fail cleanly - treat any false return as "stop parsing this message", not as "skip this one field and continue". - Writer buffer growth is a fixed 256-byte step, not a doubling growth strategy - fine for typical message sizes, needlessly slow if you build one writer instance and push megabytes through it.

Script · MT4 · v1.0 · Free

Tags: Binary Options · MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria