Files
rippled/src/ripple/protocol
Scott Schurr 17abca1caa Use macros to instantiate most SField instances:
There have been cases in the past where SFields have been defined
in such a way that they did not follow our conventions.  In
particular, the string representation of an SField should match
the in-code name of the SField.

This change leverages the preprocessor to encourage SFields to
be properly constructed.

The suffixes of SField types are changed to be the same as
the suffixes of corresponding SerializedTypeIDs.  This allows
The preprocessor to match types using simple name pasting.

Since the string representation of the SField is part of our
stable API, the name of sfPayChannel was changed to sfChannel.
This change allows sfChannel to follow our conventions while
making no changes to our external API.
2020-12-04 12:44:19 -08:00
..
2020-06-30 09:15:37 -07:00
2020-05-05 16:05:22 -07:00
2020-09-01 08:58:57 -07:00
2020-09-01 08:58:57 -07:00
2020-10-14 11:17:44 -07:00
2020-05-05 16:05:22 -07:00
2017-06-08 21:37:22 -07:00
2020-09-01 08:58:57 -07:00
2020-05-05 16:05:22 -07:00
2020-05-01 12:55:11 -07:00
2015-07-29 11:56:05 -04:00
2020-05-05 16:05:22 -07:00
2020-09-01 08:58:57 -07:00
2020-05-05 16:05:22 -07:00

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 the rippled codebase.
    • 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.

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.