Support for STL-like containers in zero-copy communication (C++ binding)

[ShanTaoDD]

Hi,

I’m currently evaluating iceoryx2 for zero-copy IPC in a C++ system.

One practical challenge is how to efficiently transmit variable-length
data structures like std::vector, std::string, or nested containers.

I understand that STL containers cannot be directly used due to:

• internal pointers not being relocatable across processes
• dynamic memory allocations outside shared memory

Currently, the recommended approach seems to be:

• flat memory layout (header + contiguous buffer)
• manual serialization or memcpy

However, from a usability and API design perspective, this introduces
friction compared to standard C++ usage.

Questions:

1. Are there plans to provide a zero-copy-friendly container abstraction
   for C++ (e.g., something like a relocatable vector or span-based container)?

2. Is there a recommended pattern for building higher-level abstractions
   on top of shared memory (e.g., for nested containers)?

3. How does the team envision bridging the gap between Rust slice-based APIs
   and C++ STL-based APIs?

4. Would a "ShmVector" abstraction (offset-based, contiguous storage)
   be aligned with the design philosophy of iceoryx2?

Thanks!

[elfenpiff]

@ShanTaoDD

1. We already provide C++ containers that are compatible with shared memory, the StaticString and StaticVector. Take a look at the Complex Data Types example to see them in action.

2. We tried to design the StaticString and StaticVector so that they look and feel as close as possible to their C++ counterparts, the std::string and std::vector. So we do not need any special patterns when using them.

3. This gap is already bridged. Take a look at the Publish Subscribe With Dynamic Data example. We introduced on C++ side a bb::Slice type that behaves like a rust slice (or in C++ terms a view). With this you can send dynamic arrays of any type. The example uses uint8_t but you can use any other type as well, for instance when you need to send a pointcloud you could use a Vec3 type for instance or when you send a RGB image you could use Vec3u (if you have such types).

4. Is your idea of a ShmVector aligning with our StaticVector implementation (https://github.com/eclipse-iceoryx/iceoryx2/blob/main/iceoryx2-bb/cxx/include/iox2/bb/static_vector.hpp) or do you have something different in mind?

Btw. All our C++ containers are memory layout compatible with their rust counterparts, so you can use them for inter-process communication between Rust and C++ as well. This is demonstrated in the "cross language communication container" and "cross language communication complex types" examples, see the overview here: https://github.com/eclipse-iceoryx/iceoryx2/tree/main/examples#overview

[ShanTaoDD]

@elfenpiff
Thank you for the detailed explanation and references.

Our current challenge mainly comes from the application side requirements. The application teams are strongly expecting to use native C++ STL containers directly (e.g. std::vector, std::string) in order to simplify portability and reduce migration effort for existing codebases.

However, as you pointed out, introducing native STL containers into shared-memory communication would inevitably require serialization/deserialization or deep-copy steps because of allocator usage and internal pointers. This would introduce additional overhead and partially defeat the purpose of zero-copy communication.

Your explanation about StaticVector, StaticString, and bb::Slice makes the design direction much clearer. I now better understand that the intention is not to make STL itself shared-memory compatible, but rather to provide STL-like containers that are deterministic, relocatable, and memory-layout-safe across processes and even across languages.

I will try to convince our application engineers to adopt the static/shared-memory-safe containers instead of relying on native STL containers directly. The cross-language memory layout compatibility between Rust and C++ is especially interesting for our future architecture plans.

Thanks again for the detailed clarification and the example references. They are very helpful for understanding the intended communication model and container philosophy of iceoryx2.

[ShanTaoDD]

We are also discussing a more experimental (and perhaps immature) idea internally:

Is there a better or more transparent way to transform native STL containers into static/shared-memory-safe containers?

For example, instead of requiring application developers to manually rewrite interfaces from std::vector/std::string to StaticVector/StaticString, perhaps there could be a transition mechanism such as:

• automatic conversion/adaptation,
• allocator-based shared-memory STL,
• compile-time/container trait transformation,
• or STL-compatible wrapper abstractions.

The motivation is mainly to reduce migration cost for large existing C++ codebases while still preserving deterministic behavior and as much zero-copy capability as possible.

We fully understand that native STL containers fundamentally depend on pointers and heap allocation, which makes true cross-process zero-copy semantics difficult or even impossible in the general case. So we are not expecting a “magic zero-copy std::vector”.

Instead, what we are wondering is whether there could be a more ergonomic bridge between:

• application-facing native STL APIs
  and
• shared-memory-safe runtime representations.

One possible direction could be:

• applications continue using STL internally,
• while the middleware layer automatically maps or converts them into StaticVector, StaticString, or bb::Slice representations during transport setup or IDL/code generation.

Another possibility might be:

• introducing a constrained/shared-memory-aware STL subset,
• where allocators, capacities, and memory layouts are controlled at compile time.

We would be very interested in hearing your thoughts on whether such a direction could align with the long-term philosophy of iceoryx2, or whether there are fundamental technical or architectural reasons why this approach would not be recommended.

Thanks again for the excellent explanations and examples.

[elfenpiff]

Hey @ShanTaoDD thank you for your ideas.

Is there a better or more transparent way to transform native STL containers into static/shared-memory-safe containers?

allocator-based shared-memory STL,

Yes, there are. If you are able to use polymorphic allocator containers like the C++ std::pmr::vector or std::pmr::string, we could get something done, but it is based on a feature where we are still looking for funding.

1. C++ allows specialization of the pointer in the allocator. If we were to create a polymorphic allocator with a relocatable pointer, we would make those pmr containers shared memory compatible.
2. [requires funding] We need the ability to resize the sample that was loaned to combine it with the polymorphic allocator. So whenever a container would allocate and the sample is too small, the underlying shared memory is resized.

With this adaptation, we could use std::pmr::{vector|string} in a completely zero-copy manner.

automatic conversion/adaptation,

This makes absolutely sense! Those conversation operators should be easy to integrate. Since we are a safety-critical project we are unable to use exceptions when a static container conversion constructor fails since its capacity is too small. The solution is, that we use static construction methods that return an expected.

Would such an API be fine for you?

std::vector<int> my_data;

auto converted_data = iox2::StaticVector<int, 123>::from_vector(my_data)
   .expect("error handling done here");

compile-time/container trait transformation,

This I didn't get, what do you mean by that?

or STL-compatible wrapper abstractions.

We could add those to iceoryx2-userland. We hesitate here again because we are a safety-critical framework, and the C++ containers do not have an API that makes them a first choice for such systems. (The API contains a lot of undefined behavior and exception-based error handling).

So I would explore other options first, but I agree that the wrappers make sense for less critical systems and that we should provide this in the long run in iceoryx2 as well.

We would be very interested in hearing your thoughts on whether such a direction could align with the long-term philosophy of iceoryx2

We see iceoryx2 as a toolbox that can be configured to support any use-case you have. Instead of forcing the user to use a specific set of things, containers, or libraries, you can mix and match as you want.
The core principle is modularity. Every layer in iceoryx2 is written so generically that it can be exchanged with another open- or closed-source solution. If you do not like to use our containers or parts of our library, you can customize them. See this: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/iceoryx2-bb/cxx/include/iox2/bb/optional.hpp. We have our own optional implementation; this is the type alias that can point to any optional that has the minimal STL API subset we require. So if you want to replace our optional with your own optional (for our entire C++ API), just change this type alias.

So your proposed solutions align very well with the long-term philosophy of iceoryx2!

I would recommend pursuing an allocator-based shared-memory STL approach. This feature would solve many other problems besides yours. Currently, users always have to make worst-case estimations for their payload, due to the static nature, and this is often harder than it looks.
It would enable Rust, C, C++, c++ and Python users to just use our API as they are used to, and this in zero-copy way - this would be awesome!

Our working mode is that we work on those bigger features when we have secured the funding for them. Either by a paying customer or some public funding. This ensures that we can continue the open-source work and maintenance of iceoryx2. So if you like to accelerate the development of this feature, you could get in contact with us: info@ekxide.io