| ▼Niox | |
| ►Ncapro | |
| ►CServiceDescription | Class 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 |
| CClassHash | |
| CCaproMessage | C'tors for CaPro messages |
| ►Nconfig | |
| ►CGatewayConfig | Generic configuration for gateways |
| CServiceEntry | |
| CTomlGatewayConfigParser | Methods for parsing gateway configs from toml text files |
| CLoggingComponent | |
| CCmdLineArgs_t | |
| CCmdLineParser | |
| CCmdLineParserConfigFileOption | |
| CRouDiConfig | |
| CTomlRouDiConfigFileProvider | |
| ►Ngw | |
| CChannel | A data structure representing a channel between Iceoryx and an external system |
| CGatewayBase | Generic gateway for communication events |
| CGatewayDiscovery | Discover the gateway |
| CGatewayGeneric | A reference generic gateway implementation |
| ►Nhelper | |
| CSetDefaults | |
| CSetDefaults< FirstArg, RemainderArgs... > | |
| CSetDefaults< FinalArg > | |
| COptimize | |
| COptimize< FirstArg, RemainderArgs... > | |
| COptimize< FinalArg > | |
| ►Nmepoo | Mepoo Component Description |
| CChunkManagement | |
| CMemPoolInfo | |
| CMemPool | |
| CMemoryManager | |
| CMePooSegment | |
| ►CSegmentManager | |
| CSegmentMapping | |
| CSegmentUserInformation | |
| CSharedPointer | DesignPattern::Creation offers us a create method which forwards the arguments to the constructor. Use this class like in the code example below |
| CSharedChunk | WARNING: SharedChunk is not thread safe! Don't share SharedChunk objects between threads! Use for each thread a separate copy |
| CShmSafeUnmanagedChunk | This 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 |
| CTypedMemPool | |
| CNoUserHeader | Helper struct to use as default template parameter when no user-header is used |
| CChunkHeader | |
| CChunkSettings | |
| CMemoryInfo | Stores properties of the memory to be used when we distinguish between different types of memory on e.g. different devices with different characteristics |
| ►CMePooConfig | |
| CEntry | |
| ►CSegmentConfig | |
| CSegmentEntry | |
| ►Npopo | |
| ►Ninternal | |
| CNoType_t | |
| CTranslateAndCallTypelessCallback | |
| CTranslateAndCallTypelessCallback< T, NoType_t > | |
| CSamplePrivateData | Helper struct for sample |
| CSamplePrivateData< const T, H > | Specialization of helper struct for sample for const T |
| CTypedUniqueId | Unique ID depending on a type. If you would like to assign different types consistent unique ids use this class. Every types gets its own distinct set of ids starting with 0. If the types are the same the ids are the same |
| CChunkDistributor | 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 |
| CChunkDistributorData | |
| CChunkQueueData | |
| CChunkQueuePopper | 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 |
| CChunkQueuePusher | 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 |
| CChunkReceiver | The ChunkReceiver is a building block of the shared memory communication infrastructure. It extends the functionality of a ChunkQueuePopper with the abililty to pass chunks to the user side (user process). Together with the ChunkSender, they are the next abstraction layer on top of ChunkDistributor and ChunkQueuePopper. The ChunkRceiver holds the ownership of the SharedChunks and does a bookkeeping which chunks are currently passed to the user side |
| CChunkReceiverData | |
| CChunkSender | The ChunkSender is a building block of the shared memory communication infrastructure. It extends the functionality of a ChunkDistributor with the abililty to allocate and free memory chunks. For getting chunks of memory the MemoryManger is used. Together with the ChunkReceiver, they are the next abstraction layer on top of ChunkDistributor and ChunkQueuePopper. The ChunkSender holds the ownership of the SharedChunks and does a bookkeeping which chunks are currently passed to the user side |
| CChunkSenderData | |
| CConditionListener | ConditionListener allows one to wait using a shared memory condition variable |
| CConditionNotifier | ConditionNotifier can notifiy waiting threads and processes using a shared memory condition variable |
| CConditionVariableData | |
| CThreadSafePolicy | |
| CSingleThreadedPolicy | |
| CInvalidId_t | Struct to signal the constructor to create an invalid id |
| CApplicationPort | |
| CApplicationPortData | |
| CBasePort | This 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 |
| CBasePortData | Defines different base port data |
| CClientPortData | |
| CClientPortRouDi | The ClientPortRouDi provides the API for accessing a client port from the RouDi middleware daemon side. The client port is divided in the three parts ClientPortData, ClientPortRouDi and ClientPortUser. The ClientPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between clients and servers ports can be established |
| CClientPortUser | The ClientPortUser provides the API for accessing a client port from the user side. The client port is divided in the three parts ClientPortData, ClientPortRouDi and ClientPortUser. The ClientPortUser uses the functionality of a ChunkSender and ChunReceiver for sending requests and receiving responses. Additionally it provides the connect / disconnect API which controls whether the client port shall connect to the server |
| CClientChunkDistributorConfig | |
| CServerChunkDistributorConfig | |
| CClientChunkQueueConfig | |
| CServerChunkQueueConfig | |
| CRPCBaseHeader | |
| CRequestHeader | |
| CResponseHeader | |
| CInterfacePort | |
| CInterfacePortData | |
| CPublisherPortData | |
| CPublisherPortRouDi | The PublisherPortRouDi provides the API for accessing a publisher port from the RouDi middleware daemon side. The publisher port is divided in the three parts PublisherPortData, PublisherPortRouDi and PublisherPortUser. The PublisherPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between publisher and subscriber ports can be established |
| CPublisherPortUser | The PublisherPortUser provides the API for accessing a publisher port from the user side. The publisher port is divided in the three parts PublisherPortData, PublisherPortRouDi and PublisherPortUser. The PublisherPortUser uses the functionality of a ChunkSender for sending shared memory chunks. Additionally it provides the offer / stopOffer API which controls whether the publisher port is discoverable for subscriber ports |
| CServerPortData | |
| CServerPortRouDi | The ServerPortRouDi provides the API for accessing a server port from the RouDi middleware daemon side. The server port is divided in the three parts ServerPortData, ServerPortRouDi and ServerPortUser. The ServerPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between clients and servers ports can be established |
| CServerPortUser | The ServerPortUser provides the API for accessing a server port from the user side. The server port is divided in the three parts ServerPortData, ServerPortRouDi and ServerPortUser. The ServerPortUser uses the functionality of a ChunkSender and ChunReceiver for receiving requests and sending responses. Additionally it provides the offer / stopOffer API which controls whether the server is discoverable for client ports |
| CSubscriberPortData | |
| CSubscriberPortMultiProducer | The SubscriberPortMultiProducer is the implementation of the SubscriberPortRouDi for a setup where subscribers can have multiple matching publishers. I.e. a n:m pub/sub deployment. The handling of CaPro messages is different for 1:m and n:m deployment |
| CSubscriberPortRouDi | The SubscriberPortRouDi provides the API for accessing a subscriber port from the RouDi middleware daemon side. The subscriber port is divided in the sevaral parts like SubscriberPortData, SubscriberPortRouDi and SubscriberPortUser. The SubscriberPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between publisher and subscriber ports can be established |
| CSubscriberPortSingleProducer | The SubscriberPortSingleProducer is the implementation of the SubscriberPortRouDi for a setup where subscriber is allowed to have only one matching publisher. I.e. a 1:m pub/sub deployment. The handling of CaPro messages is different for 1:m and n:m deployment |
| CSubscriberPortUser | The SubscriberPortUser provides the API for accessing a subscriber port from the user side. The subscriber port is divided in the parts SubscriberPortData, SubscriberPortUser and different classes for RouDi side access. The SubscriberPortUser uses the functionality of a ChunkReceiver for receiving shared memory chunks. Additionally it provides the subscribe / unsubscribe API which controls whether the subscriber ports shall try to subscribe to matching publisher ports |
| CSampleDeleter | 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 |
| CUsedChunkList | 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 |
| CBasePublisher | The BasePublisher class contains the common implementation for the different publisher specializations |
| CBaseSubscriber | Base class for all types of subscriber |
| CListener | The 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 |
| CNotificationAttorney | Class which allows accessing private methods to friends of NotificationAttorney. Used for example by the WaitSet. Implements the Client-Attorney Pattern |
| CEventCallback | |
| CNotificationCallback | Struct describes a callback with a user defined type which can be attached to a WaitSet or a Listener |
| CNotificationCallback< OriginType, internal::NoType_t > | Struct describes a callback which can be attached to a WaitSet or a Listener |
| CNotificationInfo | NotificationInfo holds the state of a trigger like the pointer to the triggerOrigin, the notification id and the callback |
| CPublisherInterface | 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 |
| CPublisherImpl | |
| CPublisherOptions | This struct is used to configure the publisher |
| CSample | The Sample class is a mutable abstraction over types which are written to loaned shared memory. These samples are publishable to the iceoryx system |
| CSubscriberImpl | |
| CSubscriberOptions | This struct is used to configure the subscriber |
| CStateBasedTrigger_t | |
| CEventBasedTrigger_t | |
| CTrigger | Usually 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 |
| CTriggerHandle | TriggerHandle 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 |
| CUntypedPublisherImpl | |
| CVoid | |
| CUntypedSubscriberImpl | |
| CUserTrigger | An 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 |
| CWaitSet | Logical disjunction of a certain number of Triggers |
| ►Nroudi | |
| CMemPoolIntrospection | 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 |
| CFixedSizeContainer | |
| CPortIntrospection | 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 |
| CProcessIntrospection | 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 |
| CMemPoolCollectionMemoryBlock | The MemPoolCollectionMemoryBlock is an implementation of a MemoryBlock for a MemPool MemoryManager |
| CMemPoolSegmentManagerMemoryBlock | |
| CPortPoolMemoryBlock | |
| CPortManager | |
| CFixedPositionContainer | Workaround container until we have a fixed list with the needed functionality |
| CPortPoolData | |
| CProcess | |
| CProcessManagerInterface | |
| CProcessManager | |
| ►CRouDi | |
| CRoudiStartupParameters | |
| ►CServiceRegistry | |
| Cinstance_t | |
| CIceOryxRouDiApp | |
| CIceOryxRouDiComponents | |
| CMemPoolInfo | Struct for the storage of mempool usage information. This data container is used by the introstpection::MemPoolInfoContainer array to store information on all available memmpools |
| CMemPoolIntrospectionInfo | Topic for the mempool introspection that a user can subscribe to |
| CPortData | Container for common port data which is related to the subscriber port as well as the publisher port |
| CPublisherPortData | Container for publisher port introspection data |
| CPortIntrospectionFieldTopic | Topic for the port introspection that a user can subscribe to |
| CPortThroughputData | |
| CPortThroughputIntrospectionFieldTopic | Topic for the port throughput that a user can subscribe to |
| CSubscriberPortChangingData | |
| CSubscriberPortChangingIntrospectionFieldTopic | |
| CProcessIntrospectionData | |
| CProcessIntrospectionFieldTopic | Topic for the process introspection that a user can subscribe to |
| CDefaultRouDiMemory | |
| CGenericMemoryBlock | The GenericMemoryBlock is an implementation of a MemoryBlock for a common use case |
| CIceOryxRouDiMemoryManager | |
| CMemoryBlock | The 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 |
| CMemoryProvider | This 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 |
| CPosixShmMemoryProvider | Creates the shared memory based on a provided configuration |
| CRouDiMemoryInterface | |
| CRouDiMemoryManager | |
| CPortPool | |
| CRouDiApp | Base class for RouDi daemons |
| CRouDiConfigFileProvider | Base class for a config file provider |
| ►Nruntime | |
| CIpcInterfaceBase | Base-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 |
| CIpcInterfaceCreator | Class for creating and handling a IPC channel |
| CIpcInterfaceUser | Class for using a IPC channel |
| CIpcMessage | |
| CIpcRuntimeInterface | |
| CNodeData | Struct which contains all the members of an object of type Node |
| CNodeProperty | Helper struct which is convertable to string and constructable from a string which is required to send the createNode request over the IPC channel |
| CSharedMemoryUser | Shared memory setup for the management segment user side |
| CNode | Class which represents a node |
| CPortConfigInfo | Stores 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) |
| CPoshRuntime | The runtime that is needed for each application to communicate with the RouDi daemon |
| CPoshRuntimeSingleProcess | |
| CConfig | |
| CDefaultChunkDistributorConfig | |
| CDefaultChunkQueueConfig | |
| CLoggingComponent | |
