[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?

[TheRedDaemon]

While testing around, I found an interesting shortcoming from our usage of sized enum values in the function declarations:
If these would be enums, we could use them to add print functions to the enums in the wrapper functions.
As it is now, the types are likely aliased ints, which prevents any kind of overload.

I will focus on the general overloads for now, but such things could be considered later.
One test also showed that an instant cast to a mutable int value in the implementation would be optimized away, should the received parameter directly be used for computations.

[gynt]

Sized enum values shouldn't be used anymore in the function declarations. Or you mean the typedef short ShortEnum things?

[TheRedDaemon]

Yes. They are basically their types and one can not overload for typedef.

Downside for using the enums as parameters types would be:

• If the original did use the plain value type and it optimized it somewhat to not use the full register (no idea if even possible), then using the enum type woulde yield another call structure.
• They can not be easily used in the function. If they are changed, they might need to use a local proxy variable to cast it to a simple value type. This works and optimizes aways, but it is somthing to consider.

The upside in the long run would be that the code does rely less on these proxy types. The only other upside I see would be the ability to customize the wrapper print for enum, but this is a very special functionality, not sure if it would be worth.

It is also something that should not lay around for too long, since this decision might effect more and more functions.
If we just keep it like it is currently, I will also reduce the approach for the << implementation, since in this case they would only truly be needed for passed value structs or bitfields.

[gynt]

Enum type variations resolved in c2e2e93