afcc4ff296
Formerly an SOTemplate was default constructed and its elements added using push_back(). This left open the possibility of a malformed SOTemplate if adding one of the elements caused a throw. With this commit the SOTemplate requires an initializer_list of its elements at construction. Elements may not be added after construction. With this approach either the SOTemplate is fully constructed with all of its elements or the constructor throws, which prevents an invalid SOTemplate from even existing. This change requires all SOTemplate construction to be adjusted at the call site. Those changes are also in this commit. The SOE_Flags enum is also renamed to SOEStyle, which harmonizes the name with other uses in the code base. SOEStyle elements are renamed (slightly) to have an "soe" prefix rather than "SOE_". This heads toward reserving identifiers with all upper case for macros. The new style also aligns with other prominent enums in the code base like the collection of TER identifiers. SOElement is adjusted so it can be stored directly in an STL container, rather than requiring storage in a unique_ptr. Correspondingly, unique_ptr usage is removed from both SOTemplate and KnownFormats.
protocol
Classes and functions for handling data and values associated with the Ripple protocol.
Serialized Objects
In ripple objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format of ripple objects.
The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.
Optional Fields
Our serialized fields have some "type magic" to make optional fields easier to read:
- The operation
x[sfFoo]means "return the value of 'Foo' if it exists, or the default value if it doesn't." - The operation
x[~sfFoo]means "return the value of 'Foo' if it exists, or nothing if it doesn't." This usage of the tilde/bitwise NOT operator is not standard outside of therippledcodebase.- As a consequence of this,
x[~sfFoo] = y[~sfFoo]assigns the value of Foo from y to x, including omitting Foo from x if it doesn't exist in y.
- As a consequence of this,
Typically, for things that are guaranteed to exist, you use
x[sfFoo] and avoid having to deal with a container that may
or may not hold a value. For things not guaranteed to exist,
you use x[~sfFoo] because you want such a container. It
avoids having to look something up twice, once just to see if
it exists and a second time to get/set its value.
(Real example)
The source of this "type magic" is in SField.h.