feat: support serialization of array, span and unordered_map

[sangelovic]

Add support for std::array, std::span and std::unordered_map in D-Bus message serialization/deserialization API.

TBD: Extending codegen XML to allow clients to choose from STL containers to use in C++ bindings?

[dleeds-cpi]

I can't wait to make use of these additions!

[sangelovic]

/cc @hellow554

[hellow554]

At at first glance, this looks very good to me :) Thanks for that! (Better than I would have done, so I'm glad you did it :D )

Just the std::tuple thing bugs me a little bit.

Also I would like to see the documentation (https://github.com/Kistler-Group/sdbus-cpp/blob/master/docs/using-sdbus-c%2B%2B.md) updated, but I can do that if you like

[sangelovic]

@hellow554 Thanks for your support here. Documentation is a good point, I forgot about it ;-) It's probably not much to update there? Would you contribute here? Will we create a new follow PR? How much time do you need?

[hellow554]

https://gist.github.com/hellow554/2a23cb29b87e4c6cac7f58d7aa96ed55

Please see this gist and apply them after you downloaded them with git am 0001-fix-some-spelling-mistakes.patch && git am 0002-docs-update-table-of-valid-c-types.patch

You can of course rebase/squash them afterwards if you like ;)

Thanks a lot :)

[sangelovic]

Done, thanks!

[sangelovic]

@hellow554

What about your open comments? Still something to discuss, or can we resolve?

And there is still one point open -- shall we also extend the code generator to be able to generate these additional containers depending on the client's choice in the D-Bus XML? I guess it will make the change consistent across all levels of API and make code generator more flexible and usable in those cases.

[hellow554]

What about your open comments? Still something to discuss, or can we resolve?

Everthing is fine :)

shall we also extend the code generator to be able to generate these additional containers depending on the client's choice in the D-Bus XML

TBH: I never used the XML generator, although I probably should have :D
I can't tell for sure, but it sounds like a good idea.
Maybe something like this:

<arg type="ai" container="std::array" name="numbers" direction="in" />

But I'm not sure if this is a feasible thing, because how does the code generator know the size of the array? Do you have to tell them, e.g. container="std::array<5>", but that feels weird, because normally you specify the type and then the length, but the type is deduced by the i after the a, isn't it?

TBH: I'm not sure how to do that in the XML and it needs some dicussion, but I don't think that it should be disucess in this PR.

I would open a new issue where one/we/other can discuss the layout of the XML.

[sangelovic]

@hellow554

We could probably use another optional XML attribute named e.g. size which would denote container size: <arg type="ai" container="std::array" size="5" name="numbers" direction="in" />. Not sure however whether adding custom attributes is allowed or whether it breaks validators or such things. Another way is to use annotations (these can be extended). For example:

<arg type="ai" name="numbers" direction="in">
    <annotation name="org.freedesktop.SdBusCpp.ContainerType" value="std::array" />
    <annotation name="org.freedesktop.SdBusCpp.ContainerSize" value="5" />
</arg>

Either way, how to address complex types? E.g. std::map<int, std::vector<std::map<std::string, std::vector<int>>> is a type of a function argument. Shall all std::vectors be replaced with std::arrays? This may be very limiting.

This needs further thinking, and I agree with you we shall do that into a separate issue/PR. We still may decide not to do that at all, if it would make things very complex.

Anyway, thanks for your contributions!