Files
rippled/include/xrpl/protocol
John Freeman ea1fffeebf Enforce levelization in libxrpl with CMake (#5111)
Adds two CMake functions:

* add_module(library subdirectory): Declares an OBJECT "library" (a CMake abstraction for a collection of object files) with sources from the given subdirectory of the given library, representing a module. Isolates the module's headers by creating a subdirectory in the build directory, e.g. .build/tmp123, that contains just a symlink, e.g. .build/tmp123/basics, to the module's header directory, e.g. include/xrpl/basics, in the source directory, and putting .build/tmp123 (but not include/xrpl) on the include path of the module sources. This prevents the module sources from including headers not explicitly linked to the module in CMake with target_link_libraries.
* target_link_modules(library scope modules...): Links the library target to each of the module targets, and removes their sources from its source list (so they are not compiled and linked twice).

Uses these functions to separate and explicitly link modules in libxrpl:

    Level 01: beast
    Level 02: basics
    Level 03: json, crypto
    Level 04: protocol
    Level 05: resource, server
2024-12-06 17:54:40 -05:00
..
2024-10-15 18:27:56 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:14 -05:00
2024-10-15 18:27:56 -05:00
2024-06-20 13:57:16 -05:00
2024-12-03 14:54:44 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:14 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-12-03 14:54:44 -05:00
2024-06-20 13:57:14 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:14 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-10-15 18:27:56 -05:00
2024-12-03 14:54:44 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-06-20 13:57:16 -05:00
2024-12-03 14:54:44 -05:00
2024-06-20 13:57:16 -05:00

protocol

Classes and functions for handling data and values associated with the XRP Ledger protocol.

Serialized Objects

Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.

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.