<< operator for modm::can::Message in generated code

[strongly-typed]

I have a problem with modm::can::Message

It works in a file included from main.cpp but not in generated code.

./modm/src/modm/communication/other/other_impl.hpp:15:17: error: no match for 'operator<<' (operand types are 'modm::log::Logger' and 'modm::can::Message')
   15 |  MODM_LOG_DEBUG << tx;
      |                 ^~ ~~
      |                    |
      |                    modm::can::Message

I have an example here

Compiles from main

and from examples/linux/logger/other_impl.hpp

but not in modm/communication/other/other_impl.hpp

The generated code in ./modm/src/modm/architecture/interface/can_message.hpp has the operator << included.

I probably do something completely wrong here ... but I cannot see it. Any suggestions?

[mikewolfram]

Did you had a look into the preprocessor output? And what is the full error message?

BTW: In operator <<, do you copy the message by purpose?

[strongly-typed]

You can see the full error message in the CI

The preprocessor output[1] is here. modm::IOStream& operator << (modm::IOStream& s, const modm::can::Message m); is in the output.

BTW: No copying intended, but it just worked ;-) Yes, let this change once this error is resolved.

[1] created with

/usr/local/bin/g++-10  -I/usr/local/include -I/Users/sascha/Dev/modm/modm-str-logger-canmessage/examples/linux/logger/modm/ext -I/Users/sascha/Dev/modm/modm-str-logger-canmessage/examples/linux/logger/modm/src -I/Users/sascha/Dev/modm/modm-str-logger-canmessage/examples/linux/logger -fdata-sections     -ffunction-sections     -finline-limit=10000     -funsigned-bitfields     -funsigned-char     -fwrapv     -g3     -gdwarf-3     -W     -Wall     -Wduplicated-cond     -Werror=format     -Werror=maybe-uninitialized     -Werror=overflow     -Werror=sign-compare     -Wextra     -Wlogical-op     -Wno-redundant-decls     -Wpointer-arith     -Wundef      -fstrict-enums     -std=c++17     -Woverloaded-virtual   -E   -Os  -o CMakeFiles/logger.dir/main.cpp.obj -c /Users/sascha/Dev/modm/modm-str-logger-canmessage/examples/linux/logger/main.cpp

[mikewolfram]

Strange. Moving the operator

modm::IOStream&
operator << (modm::IOStream& s, const modm::can::Message &m);

into the modm::can namespace compiles without issues.

[strongly-typed]

I'll try as well.

My previous experience, if I remember correctly, was, that it must be outside of the modm::can namespace. Very strange.

[salkinium]

Include order perhaps? It doesn't look wrong to me though… 🤨

[mikewolfram]

I spent lot of time looking through the precompiled output to see, if the includes are in wrong order etc. But everything was fine.
But then I also remembered reading a (very) long time ago that some operators need to be defined in the namespace where the class/struct is defined. I think here's the explanation: https://en.cppreference.com/w/cpp/language/adl

[chris-durand]

The reason why this doesn't work are the arcane rules of C++ name lookup. MODM_LOG_DEBUG is a modm::log::Logger which inherits from modm::IOStream. When you write MODM_LOG_DEBUG << tx; the compiler will at first try to find member function candidates in modm::logger::Log for operator<<. It will find some in the base class.

In the next step it searches for non-member function candidates using the rules of unqualified lookup, which may include candidates found by ADL. The union of both sets is used in overload resolution.

The expected operator is defined in the global namespace. That's the reason the generated code fails which is inside namespace modm. Unqualified lookup finds some other operators operator << (modm::IOStream& stream, … inside of the modm namespace and stops. The correct operator is not considered in the lookup process. For main.cpp it finds the right operator in the global namespace.

You could move the operator to namespace modm or modm::can. In any case it will be found by ADL.

[chris-durand]

For the same reason the following example does not compile: https://gcc.godbolt.org/z/bsdYqE

[strongly-typed]

#512 works for me. Let's work on the PR and I close the issue