Repository navigation
[TEMPLATE] The "<<" operator is not guaranteed to be available for arbitrary types #28
Description
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
Metadata
Metadata
Assignees
Labels
No labels
Activity
TheRedDaemon commentedon Jan 4, 2026
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 commentedon May 4, 2026
After #55 we are left with the question where to place the overloads of the
<<method in the file tree.TheRedDaemon:
I would also say in the
corefolder. As<<is quite a generic overload specifically for logging. What about a subfolderloggingthat contains a fileltlt_operator_overloads.cpphttps://en.cppreference.com/cpp/io/basic_ostream/operator_ltltTheRedDaemon commentedon May 13, 2026
Considering "core" is very empty and even might stay empty:
If we put every overload into one file, then I think
ltlt_operator_overloads.cppcould also be directly in core, without another subfolder.gynt commentedon May 19, 2026
Sounds good! Can I assign you to it?
TheRedDaemon commentedon Jun 2, 2026
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 commentedon Jun 3, 2026
Sized enum values shouldn't be used anymore in the function declarations. Or you mean the
typedef short ShortEnumthings?TheRedDaemon commentedon Jun 11, 2026
Yes. They are basically their types and one can not overload for
typedef.Downside for using the enums as parameters types would be:
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 commentedon Jun 14, 2026
Enum type variations resolved in c2e2e93