Supported STL Types
The marshalling library has inbuilt support for marshalling a large number of STL objects, including all members of the containers library. The following is a list of types provided by the C++ STL for which marshalling is natively supported by the marshalling library:
- std::vector
- std::array (C++11)
- std::list
- std::forward_list (C++11)
- std::deque
- std::set
- std::multiset
- std::unordered_set (C++11)
- std::unordered_multiset (C++11)
- std::map
- std::multimap
- std::unordered_map (C++11)
- std::unordered_multimap (C++11)
- std::stack
- std::queue
- std::priority_queue
- std::basic_string (IE, std::string, std::wstring, etc)
- std::pair
- std::tuple (C++11)
- std::unique_ptr (C++11)
In addition to these types that are natively supported by the marshalling library, the following STL types do not require marshalling, as the specification requires them to have a precise memory layout which is guaranteed across implementations:
- std::complex
Nested STL Container Types
In addition to supporting marshalling STL types directly, native support is also provided for marshalling STL objects that are nested within each other. For example, an object with the following definition can be marshalled successfully with no additional effort:
std::list<std::vector<std::map<std::string, std::queue<std::tuple<int, std::wstring>>>>> someComplexObject;
Unsupported STL Types
There are several STL types for which marshalling is not currently supported, where an expectation may exist that they would be supported. They will be listed and discussed in this section.
std::bitset and std::valarray
The std::bitset and std::valarray types are not currently supported by the marshalling library. There is no technical reason why this is the case, it is simply because of their slightly obscure nature that support hasn't been included at this time. Support for these types may be added in the future.
std::shared_ptr and std::weak_ptr
The std::shared_ptr and std::weak_ptr types are not currently supported by the marshalling library. Although the reference counting mechanism can be made to work across assembly boundaries, there are potential performance and memory usage problems if the same pointer is passed between assemblies repeatedly. Future enhancements are possible in this area, which may add a level of support for these pointer types.
std::auto_ptr
Since std::auto_ptr is deprecated and pending removal from the C++ standard, no attempt has been made to support it in the marshalling library. Please use std::unique_ptr if you are using a C++11 conforming compiler, or consider passing raw pointers with custom deallocation routines in C++03.
STL Containers with Special Requirements
std::basic_string
The std::basic_string class is fully supported in the marshalling library, with the special provision that the character type used with the string doesn't require marshalling itself. Any primitive type such as char, or any "C" style custom structure which is composed exclusively of primitive types satisfies this requirement. If for some reason you need a custom string type which uses std::basic_string and requires marshalling for its elements, consider using the std::vector container when marshalling, which does support marshalling its elements. This restriction may be lifted in future versions of the marshalling library.
std::unique_ptr
The std::unique_ptr type is supported by the marshalling library, however please note that the std::default_delete type, which is used as the default deleter for these pointers, will attempt to free heap memory across assembly boundaries. The marshalling library doesn't prohibit the use of the std::unique_ptr type with the std::default_delete deleter selected however, as if you are passing a custom interface type between assemblies which uses a custom delete operator and redirects to a virtual method, the operation is safe. Since this is seen as one of the most common use cases of marshalling std::unique_ptr instances, the std::default_delete type is not prohibited. If you are attempting to marshal a resource which doesn't have a custom delete operator that resolves memory deallocation issues across assembly boundaries, please use the MarshallableDelete deleter, which will ensure deletion occurs from the same assembly that constructed the original instance of the pointer.
Examples
For usage examples of how to marshal STL types, please refer to the examples section in the Marshal::In, Marshal::Out, Marshal::InOut, and Marshal::Ret sections.