rclcpp_action::GoalUUID Struct Reference

#include <server.hpp>

Public Member Functions
uint8_t *	data ()
	Pointer to the 16 bytes — what the raw-array overloads and the FFI take.
const uint8_t *	data () const
	GoalUUID ()
	The zero ("null") goal id — mirrors nros_core::GoalId::zero().
	GoalUUID (const uint8_t *src)
	Copy the 16 bytes at src, which must point to at least that many.
bool	is_zero () const
	True when every byte is zero — mirrors nros_core::GoalId::is_zero().
bool	operator!= (const GoalUUID &other) const
bool	operator< (const GoalUUID &other) const
bool	operator== (const GoalUUID &other) const

Public Attributes
uint8_t	uuid [16]
	UUID bytes, in wire order.

Static Public Attributes
static const size_t	SIZE = 16
	Byte count — unique_identifier_msgs/UUID is a fixed uint8[16].

Detailed Description

Value type for a goal identifier — the 16 bytes ROS 2 carries as unique_identifier_msgs/msg/UUID.

Phase-417 W4.b. Every action signature here spelled the goal id const uint8_t goal_id[16], which DECAYS to a pointer: it cannot be compared with ==, cannot be returned by value, and cannot be stored in a container. rclcpp_action::GoalUUID is a std::array<uint8_t, 16> and is a map key in most real action servers, so the array-decay spelling is a drop-in BLOCKER rather than a style difference.

C has had rclc_goal_uuid_t (rclc/detail/nros_generated.h) and Rust nros_core::GoalId all along; C++ was the odd one out. This is a value type over the SAME 16 bytes, not a second identity scheme: standard layout, trivially copyable, sizeof == 16, no allocator, no call into anything — so it reaches every target the freestanding headers do.

Generation is deliberately NOT here. C's rclc_goal_uuid_generate draws randomness, which is behaviour, and RFC-0019 keeps behaviour Rust-side; the goal id a server sees is the one the FFI hands it.

The raw const uint8_t[16] overloads are kept beside every GoalUUID one: the FFI trampolines hand callbacks a const uint8_t[16], and in-tree examples spell it that way in their own callback signatures. The converting constructor is explicit so a raw-array call site still selects the raw-array overload rather than silently converting.

Constructor & Destructor Documentation

GoalUUID() [1/2]

rclcpp_action::GoalUUID::GoalUUID ( )

inline

The zero ("null") goal id — mirrors nros_core::GoalId::zero().

GoalUUID() [2/2]

rclcpp_action::GoalUUID::GoalUUID ( const uint8_t *  src )

inlineexplicit

Copy the 16 bytes at src, which must point to at least that many.

Member Function Documentation

data() [1/2]

uint8_t * rclcpp_action::GoalUUID::data ( )

inline

Pointer to the 16 bytes — what the raw-array overloads and the FFI take.

data() [2/2]

const uint8_t * rclcpp_action::GoalUUID::data ( ) const

inline

is_zero()

bool rclcpp_action::GoalUUID::is_zero ( ) const

inline

True when every byte is zero — mirrors nros_core::GoalId::is_zero().

operator!=()

bool rclcpp_action::GoalUUID::operator!= ( const GoalUUID &  other ) const

inline

operator<()

bool rclcpp_action::GoalUUID::operator< ( const GoalUUID &  other ) const

inline

Lexicographic order over the 16 bytes, so GoalUUID is usable as a std::map key — the shape rclcpp_action::GoalUUID gets for free by being a std::array. The ordering carries no meaning beyond that.

operator==()

bool rclcpp_action::GoalUUID::operator== ( const GoalUUID &  other ) const

inline

Member Data Documentation

SIZE

const size_t rclcpp_action::GoalUUID::SIZE = 16

static

Byte count — unique_identifier_msgs/UUID is a fixed uint8[16].

uuid

uint8_t rclcpp_action::GoalUUID::uuid[16]

UUID bytes, in wire order.

---

The documentation for this struct was generated from the following file:

• include/rclcpp_action/server.hpp