iceoryx_doc  1.0.1
Class Hierarchy

Go to the graphical class hierarchy

This inheritance list is sorted roughly, but not completely, alphabetically:
[detail level 123]
 Ciox::popo::BasePortThis class is the base for all ports. it is constructed from a member pointer and is only movable. only movable rational: a port has only one member, a pointer to its data. if a port is copied then both ports would work on the same data even though these are two independent copies. this would case a weird shared state, race conditions and so on
 Ciox::popo::BasePortDataDefines different base port data
 Ciox::popo::BasePublisher< port_t >The BasePublisher class contains the common implementation for the different publisher specializations
 Ciox::popo::BaseSubscriber< port_t >Base class for all types of subscriber
 Ciox::capro::CaproMessageC'tors for CaPro messages
 Ciox::gw::Channel< IceoryxTerminal, ExternalTerminal >A data structure representing a channel between Iceoryx and an external system
 Ciox::popo::ChunkDistributor< ChunkDistributorDataType >The ChunkDistributor is the low layer building block to send SharedChunks to a dynamic number of ChunkQueus. Together with the ChunkQueuePusher, the ChunkDistributor builds the infrastructure to exchange memory chunks between different data producers and consumers that could be located in different processes. Besides a modifiable container of ChunkQueues to which a SharedChunk can be deliverd, it holds a configurable history of last sent chunks. This allows to provide a newly added queue a number of last chunks to start from. This is needed for functionality known as latched topic in ROS or field in ara::com. A ChunkDistributor is used to build elements of higher abstraction layers that also do memory managemet and provide an API towards the real user
 Ciox::popo::ChunkDistributor< ChunkSenderDataType::ChunkDistributorData_t >
 CChunkDistributorData_t
 CChunkDistributorDataType
 Ciox::mepoo::ChunkHeader
 Ciox::mepoo::ChunkManagement
 CChunkQueueData_t
 CChunkQueueDataType
 Ciox::popo::ChunkQueuePopper< ChunkQueueDataType >The ChunkQueuePopper is the low layer building block to receive SharedChunks. It follows a first-in-first-out principle. Together with the ChunkDistributor and the ChunkQueuePusher, the ChunkQueuePopper builds the infrastructure to exchange memory chunks between different data producers and consumers that could be located in different processes. A ChunkQueuePopper is used to build elements of higher abstraction layers that also do memory managemet and provide an API towards the real user
 Ciox::popo::ChunkQueuePopper< ChunkReceiverDataType::ChunkQueueData_t >
 Ciox::popo::ChunkQueuePusher< ChunkQueueDataType >The ChunkQueuePusher is the low layer building block to push SharedChunks in a chunk queue. Together with the ChunkDistributor and ChunkQueuePopper the ChunkQueuePusher builds the infrastructure to exchange memory chunks between different data producers and consumers that could be located in different processes. A ChunkQueuePusher is the part of the chunk queue that is knwon by the ChunkDistributor
 Ciox::mepoo::ChunkSettings
 Ciox::capro::ServiceDescription::ClassHash
 Ciox::popo::ClientChunkDistributorConfig
 Ciox::popo::ClientChunkQueueConfig
 Ciox::config::CmdLineArgs_t
 Ciox::config::CmdLineParser
 Ciox::popo::ConditionListenerConditionListener allows one to wait using a shared memory condition variable
 Ciox::popo::ConditionNotifierConditionNotifier can notifiy waiting threads and processes using a shared memory condition variable
 Ciox::popo::ConditionVariableData
 CConfigParts
 CDesignPattern::Creation
 Ciox::DefaultChunkDistributorConfig
 Ciox::DefaultChunkQueueConfig
 Ciox::roudi::DefaultRouDiMemory
 Ciox::mepoo::MePooConfig::Entry
 Ciox::popo::EventBasedTrigger_t
 Ciox::popo::EventCallback< OriginType, ContextDataType >
 Ciox::roudi::FixedPositionContainer< T, Capacity >Workaround container until we have a fixed list with the needed functionality
 Ciox::roudi::FixedPositionContainer< iox::popo::ApplicationPortData, MAX_PROCESS_NUMBER >
 Ciox::roudi::FixedPositionContainer< iox::popo::ConditionVariableData, MAX_NUMBER_OF_CONDITION_VARIABLES >
 Ciox::roudi::FixedPositionContainer< iox::popo::InterfacePortData, MAX_INTERFACE_NUMBER >
 Ciox::roudi::FixedPositionContainer< iox::popo::PublisherPortData, MAX_PUBLISHERS >
 Ciox::roudi::FixedPositionContainer< iox::popo::SubscriberPortData, MAX_SUBSCRIBERS >
 Ciox::roudi::FixedPositionContainer< iox::runtime::NodeData, MAX_NODE_NUMBER >
 Ciox::roudi::FixedSizeContainer< T, capacity >
 Ciox::roudi::FixedSizeContainer< ConnectionInfo, MAX_SUBSCRIBERS >
 Ciox::roudi::FixedSizeContainer< PublisherInfo, MAX_PUBLISHERS >
 Ciox::gw::GatewayBaseGeneric gateway for communication events
 Ciox::config::GatewayConfigGeneric configuration for gateways
 Ciox::gw::GatewayDiscovery< Impl_T >Discover the gateway
 Ciox::roudi::IceOryxRouDiComponents
 Ciox::roudi::ServiceRegistry::instance_t
 Ciox::popo::InvalidId_tStruct to signal the constructor to create an invalid id
 Ciox::runtime::IpcInterfaceBaseBase-Class should never be used by the end-user. Handles the common properties and methods for the childs. The handling of the IPC channels must be done by the children
 Ciox::runtime::IpcMessage
 Ciox::runtime::IpcRuntimeInterface
 Ciox::popo::ListenerThe Listener is a class which reacts to registered events by executing a corresponding callback concurrently. This is achieved via an encapsulated thread inside this class
 CLockingPolicy
 Ciox::config::LoggingComponent
 Ciox::LoggingComponent
 Ciox::roudi::MemoryBlockThe MemoryBlock is a container for general purpose memory. It is used to request some memory from a MemoryProvider, which can be POSIX SHM, the stack or something completely different. To be able to use the container, some functions need to be implemented. For most use cases the GenericMemoryBlock can be used, which is a templated class and implements the most common case
 Ciox::mepoo::MemoryInfoStores properties of the memory to be used when we distinguish between different types of memory on e.g. different devices with different characteristics
 Ciox::mepoo::MemoryManager
 Ciox::roudi::MemoryProviderThis class creates memory which is requested by the MemoryBlocks. Once the memory is available, this is announced to the blocks, so that they can consume the memory for their needs. When the Memory is release, the blocks will also called to handle this appropriately, e.g. calling the destructor of the underlying type. This class is an interface with some default behavior and needs an implementation for real memory supply, e.g. a PosixShmMemoryProvider
 Ciox::mepoo::MemPool
 Ciox::mepoo::MemPoolInfo
 Ciox::roudi::MemPoolInfoStruct for the storage of mempool usage information. This data container is used by the introstpection::MemPoolInfoContainer array to store information on all available memmpools
 Ciox::roudi::MemPoolIntrospection< MemoryManager, SegmentManager, PublisherPort >This class handles the mempool intropection for RouDi. It is recommended to use the MemPoolIntrospectionType alias which sets the intended template parameters required for the actual introspection. The class sends snapshots of the mempool usage to the introspection client if subscribed
 Ciox::roudi::MemPoolIntrospection< mepoo::MemoryManager, mepoo::SegmentManager<>, PublisherPortUserType >
 Ciox::roudi::MemPoolIntrospectionInfoTopic for the mempool introspection that a user can subscribe to
 Ciox::mepoo::MePooConfig
 Ciox::mepoo::MePooSegment< SharedMemoryObjectType, MemoryManagerType >
 Ccxx::NewType
 Ciox::runtime::NodeClass which represents a node
 Ciox::runtime::NodeDataStruct which contains all the members of an object of type Node
 Ciox::runtime::NodePropertyHelper struct which is convertable to string and constructable from a string which is required to send the createNode request over the IPC channel
 Ciox::popo::NotificationAttorneyClass which allows accessing private methods to friends of NotificationAttorney. Used for example by the WaitSet. Implements the Client-Attorney Pattern
 Ciox::popo::NotificationCallback< OriginType, ContextDataType >Struct describes a callback with a user defined type which can be attached to a WaitSet or a Listener
 Ciox::popo::NotificationCallback< OriginType, internal::NoType_t >Struct describes a callback which can be attached to a WaitSet or a Listener
 Ciox::popo::NotificationInfoNotificationInfo holds the state of a trigger like the pointer to the triggerOrigin, the notification id and the callback
 Ciox::popo::internal::NoType_t
 Ciox::mepoo::NoUserHeaderHelper struct to use as default template parameter when no user-header is used
 Ciox::helper::Optimize< ConfigParts >
 Ciox::helper::Optimize< FinalArg >
 Ciox::helper::Optimize< FirstArg, RemainderArgs... >
 Ciox::runtime::PortConfigInfoStores information necessary to create the right type of port on RouDi side. Different types of ports are required if e.g. different types of shared memory are used (e.g. on GPU)
 Ciox::roudi::PortDataContainer for common port data which is related to the subscriber port as well as the publisher port
 Ciox::roudi::PortIntrospection< PublisherPort, SubscriberPort >This class handles the port introspection for RouDi. It is recommended to use the PortIntrospectionType alias which sets the intended template parameter required for the actual introspection. The class manages a thread that periodically updates a field with port introspection data to which clients may subscribe
 Ciox::roudi::PortIntrospection< PublisherPortUserType, SubscriberPortUserType >
 Ciox::roudi::PortIntrospectionFieldTopicTopic for the port introspection that a user can subscribe to
 Ciox::roudi::PortManager
 Ciox::roudi::PortPool
 Ciox::roudi::PortPoolData
 Ciox::roudi::PortThroughputData
 Ciox::roudi::PortThroughputIntrospectionFieldTopicTopic for the port throughput that a user can subscribe to
 Ciox::runtime::PoshRuntimeThe runtime that is needed for each application to communicate with the RouDi daemon
 Ciox::roudi::Process
 Ciox::roudi::ProcessIntrospection< PublisherPort >This class handles the process intropection for RouDi. It is recommended to use the ProcessIntrospectionType alias which sets the intended template parameter. The class tracks the adding and removal of processes and sends it to the introspection client if subscribed
 Ciox::roudi::ProcessIntrospection< PublisherPortUserType >
 Ciox::roudi::ProcessIntrospectionData
 Ciox::roudi::ProcessIntrospectionFieldTopicTopic for the process introspection that a user can subscribe to
 Ciox::roudi::ProcessManagerInterface
 Ciox::popo::PublisherInterface< T, H >The PublisherInterface class defines the publisher interface used by the Sample class to make it generic. This allows any publisher specialization to be stored as a reference by the Sample class. It is also needed to avoid circular dependencies between Sample and Publisher
 Ciox::popo::PublisherInterface< T, mepoo::NoUserHeader >
 Ciox::popo::PublisherOptionsThis struct is used to configure the publisher
 Ciox::roudi::RouDi
 Ciox::roudi::RouDiAppBase class for RouDi daemons
 Ciox::config::RouDiConfig
 Ciox::roudi::RouDiConfigFileProviderBase class for a config file provider
 Ciox::roudi::RouDiMemoryInterface
 Ciox::roudi::RouDiMemoryManager
 Ciox::roudi::RouDi::RoudiStartupParameters
 Ciox::popo::RPCBaseHeader
 Ciox::popo::Sample< T, H >The Sample class is a mutable abstraction over types which are written to loaned shared memory. These samples are publishable to the iceoryx system
 Ciox::popo::SampleDeleter< Port >The SampleDeleter struct is a custom deleter in functor form which releases loans to a sample's underlying memory chunk via the corresponding port.. Each port should create its own instance of this deleter struct
 Ciox::popo::SampleDeleter< PortType >
 Ciox::popo::SampleDeleter< typename BasePublisher_t::PortType >
 Ciox::popo::internal::SamplePrivateData< T, H >Helper struct for sample
 Ciox::popo::internal::SamplePrivateData< const T, H >Specialization of helper struct for sample for const T
 Ciox::popo::internal::SamplePrivateData< T, cxx::add_const_conditionally_t< mepoo::NoUserHeader, T > >
 Ciox::mepoo::SegmentConfig
 Ciox::mepoo::SegmentConfig::SegmentEntry
 Ciox::mepoo::SegmentManager< SegmentType >
 Ciox::mepoo::SegmentManager< SegmentType >::SegmentMapping
 Ciox::mepoo::SegmentManager< SegmentType >::SegmentUserInformation
 Ciox::popo::ServerChunkDistributorConfig
 Ciox::popo::ServerChunkQueueConfig
 Ciox::capro::ServiceDescriptionClass for the identification of a communication event including information on the service, the service instance and the event id. In order to support different communication protocols, two types of members exist: integer and string identifiers. If string IDs are used, the integers are initialized to an invalid number. A class object can be serialized/deserialized, so it is possible to send the information e.g. over a IPC channel
 Ciox::config::GatewayConfig::ServiceEntry
 Ciox::roudi::ServiceRegistry
 Ciox::helper::SetDefaults< ConfigParts >
 Ciox::helper::SetDefaults< FinalArg >
 Ciox::helper::SetDefaults< FirstArg, RemainderArgs... >
 Ciox::mepoo::SharedChunkWARNING: SharedChunk is not thread safe! Don't share SharedChunk objects between threads! Use for each thread a separate copy
 Ciox::runtime::SharedMemoryUserShared memory setup for the management segment user side
 Ciox::mepoo::ShmSafeUnmanagedChunkThis class to safely store a chunk in shared memory. To be able to do so, torn writes/reads need to prevented, since they create Frankenstein objects. Therefore, the class must not be larger than 64 bits and trivially copy-able in case an application dies while writing this and RouDi needs to clean up
 Ciox::popo::SingleThreadedPolicy
 Ciox::popo::StateBasedTrigger_t
 Ciox::popo::SubscriberOptionsThis struct is used to configure the subscriber
 Ciox::roudi::SubscriberPortChangingData
 Ciox::roudi::SubscriberPortChangingIntrospectionFieldTopic
 Ciox::popo::ThreadSafePolicy
 Ciox::config::TomlGatewayConfigParserMethods for parsing gateway configs from toml text files
 Ciox::popo::internal::TranslateAndCallTypelessCallback< T, ContextDataType >
 Ciox::popo::internal::TranslateAndCallTypelessCallback< T, NoType_t >
 Ciox::popo::TriggerUsually managed by a factory class like a WaitSet and acquired by classes which would like to signal a notification. Multiple Trigger can share a common ConditionVariableData pointer so that multiple Trigger can signal a single instance
 Ciox::popo::TriggerHandleTriggerHandle is threadsafe without restrictions in a single process. Not qualified for inter process usage. The TriggerHandle is generated by a Notifyable like the WaitSet and handed out to the user when they acquire a trigger. The TriggerHandle corresponds with an internal Trigger and is used to signal an event via the trigger method. When it goes out of scope it cleans up the corresponding trigger in the Notifyable
 Ciox::mepoo::TypedMemPool< T >
 Ciox::popo::UsedChunkList< Capacity >This class is used to keep track of the chunks currently in use by the application. In case the application terminates while holding chunks, this list is used by RouDi to retain ownership of the chunks and prevent a chunk leak. In order to always be able to access the used chunks, neither a vector or list can be used, because these container could be corrupted when the application dies in the wrong moment. To be able to do the cleanup, RouDi needs to be able to access the list with the used chunk under all circumstances. This is achieved by storing the ChunkManagement pointer in an array which can always be accessed. Additionally, the type stored is this array must be less or equal to 64 bit in order to write it within one clock cycle to prevent torn writes, which would corrupt the list and could potentially crash RouDi
 Ciox::popo::UsedChunkList< MAX_CHUNKS_IN_USE >
 Ciox::popo::UsedChunkList< MaxChunksAllocatedSimultaneously >
 Ciox::popo::UserTriggerAn event based trigger which can be used by the application developer directly. If you would like to trigger a WaitSet/Listener through an event of your class you should use the Trigger class
 Ciox::popo::Void
 Ciox::popo::WaitSet< Capacity >Logical disjunction of a certain number of Triggers