Skip to content

Dynamic Devices#

The aes70::dynamic_device namespace provides a flexible, runtime-modifiable representation of an AES70 device model. It is designed around a block-based structure in which device functionality is described and organized.

  • Container-based design The library uses standard C++ containers to store objects, with ownership managed primarily through std::shared_ptr. This ensures safe, automatic lifetime management of dynamically created elements.

  • Blocks and object ownership The core unit is the dynamic_device::block, which maintains its children in a std::vector. Conceptually, each block owns the objects it contains—removing a block from its parent automatically destroys its child objects as well.

  • Dynamic modification Blocks can be extended, reconfigured, or removed at runtime. Any such changes are communicated to connected controllers, allowing external systems to stay synchronized with the device’s current structure.

Object creation#

New child objects are typically created via the generic API:

auto object = block->create_child<Type>(...);

For convenience, blocks can be created using the shorthand:

auto subblock = block->create_block(RoleName);

Device Implementations#

Within the aes70::dynamic_device namespace, two main device implementations are provided to balance flexibility and efficiency depending on the use case:

  • aes70::dynamic_device::device This implementation maintains an internal hash map lookup table for resolving objects by their object numbers.

    • Well-suited for dynamic scenarios where blocks and objects are created and removed at runtime.
    • Provides efficient lookup even as the device structure changes.
    • Slightly higher memory overhead compared to the linear implementation, due to the hash map.

  • aes70::dynamic_device::linear_device This variant stores objects in a vector indexed by object number, giving a compact and fast-access representation.

    • Best used in static or semi-static configurations where all objects are created once during initialization and remain unchanged.
    • Offers lower memory usage and faster lookups than the hash map approach.
    • Not designed for frequent object removal or restructuring.

In practice, the choice depends on the device’s lifecycle: