[TEMPLATE] The "<<" operator is not guaranteed to be available for arbitrary types

[gynt]

For example, if a function argument is of type MapperCommandUnion, compilation fails because the compiler cannot find a way to use << on that type.

Steps to reproduce are to define a FunctionResolver instance for a function with non-simple argument types, such as MapperCommandUnion. Then try to compile.

I think it is caused here:

OpenSHC/src/precomp/FunctionResolver.h

Line 219 in 01f9035

#define MACRO_STREAM_PRINT_PARAMETER_LIST(N) MACRO_INDEX_ITERATE_DEPTH_0(N, MACRO_STREAM_PRINT_PARAMETER, << ", ")

[TheRedDaemon]

First thing:
The error should only happen if the "Wrapper" is active. If this happens otherwise, I need to check the resolver again.

Second:
I am actually aware. There is no default handling for value types that are not primitives or other pointers. C++ has no idea how to print these values and there is no way to automate this.
So, assuming we want to use the resolver method and want to keep the call log option, we would need to define the overloads somewhere.
Since we are not afraid of files, I would say we would create additional C++ files with the overloads for all types that require it.

[gynt]

After #55 we are left with the question where to place the overloads of the << method in the file tree.

TheRedDaemon:

there would also be the question where those print definitions should be stored. I would be [in favor of] some sub-folder of core.

I would also say in the core folder. As << is quite a generic overload specifically for logging. What about a subfolder logging that contains a file ltlt_operator_overloads.cpp https://en.cppreference.com/cpp/io/basic_ostream/operator_ltlt

[TheRedDaemon]

Considering "core" is very empty and even might stay empty:
If we put every overload into one file, then I think ltlt_operator_overloads.cpp could also be directly in core, without another subfolder.

[gynt]

Sounds good! Can I assign you to it?