Serializing bs::Map?


I was wondering how bs::Map could be serialized. It seems like the makros provided by the RTTI-headers only work on bs::Vector.

Of course I could modify the class I am trying to serialize to store key/value pairs but i’d rather not do that.
Is there some code I can look at which serializes a bs::Map?


I see that there is indeed a template specialization for std::map, I guess this is supposed to work and I just don’t get it right.

I have map of type bs::Map<UINT32, ScriptObject> where ScriptObject is a class implementing IReflectable.

When adding it via BS_RTTI_MEMBER_PLAIN I get a complaint that the value type is not POD:

/home/andre/code/REGoth-bs/lib/bsf/Source/Foundation/bsfUtility/Prerequisites/BsRTTIPrerequisites.h:43:17: error: static assertion failed: 
Provided type isn't plain-old-data. You need to specialize RTTIPlainType template in order to serialize this type.  
(Or call BS_ALLOW_MEMCPY_SERIALIZATION(type) macro if you are sure the type can be properly serialized using just memcpy.)

If I add it via BS_RTTI_MEMBER_REFL I get:

/home/andre/code/REGoth-bs/lib/bsf/Source/Foundation/bsfUtility/Reflection/BsRTTIType.h:587:19: error: static assertion failed: 
Invalid data type for complex field. It needs to derive from bs::IReflectable.
    static_assert((std::is_base_of<bs::IReflectable, DataType>::value),


Map is serialized as a plain type, and plain types can hold reference to other plain types (meaning no references to IReflectable objects).

There are some plans to add generic iterator support to IReflectable, that would work with maps as well as vectors, but it hasn’t been added yet.

For now you can either:

  • Wrap your IReflectable type in a plain type, then for that type implement a RTTIPlainType specialization that uses BinarySerializer to manually serialize/deserialize the IReflectable object.
  • Convert the map to a temporary Vector in onSerializationStarted callback in RTTIType, and write the vector. Then in onDeserializationEnded decode the vector back into a map. This is probably the preferred approach at the moment.