Use `no_std`-compatible printing in Rust/C/C++/Python examples

[orecham]

Brief Description

The examples currently use the language-specific printing mechanisms which rely on the standard library. These should be replaced with an alternative that allows them to be compiled and run in no_std contexts.

Potential solutions:

1. Add own printing abstraction to iceoryx2-bb that can be implemented for the target platform
2. Use writeln! and core::fmt::Write which can be implemented for the target platform

[elBoberido]

That's deliberate. I don't remember exactly why, though. Maybe @elfenpiff can shed some light on this.

[elfenpiff]

@orecham @elBoberido I agree, lets route the C & C++ console output through iceoryx2 logging abstraction. We could also do this for the python examples - maybe they work then also out of the box in micropython

[elBoberido]

@elfenpiff @orecham I think I now remember why we did not use the logger. Essentially, it is application output and not logging output. We also use stderr for the logging output instead of stdout. See also #885

There are also other issues with this approach. For example, a user could set the IOX2_LOG_LEVEL env variable to error or configures iceoryx2 in a way to use the file logger by default. In this case the examples wouldn't output anything. Furthermore, it would probably make the end-to-end tests a bit more complex to write.

I also don't think there is a no_std equivalent for C++. There might be cases where only a subset of the STL is certified, but I would be surprised if the printing parts of the STL wouldn't be there as QM.

[orecham]

@elBoberido @elfenpiff How about adding another function to the logger, like our own println!, that outputs to stdout? I initially had this idea but opted just to use info! to reduce some of the up-front effort. The initial complexity I encountered is that some of the existing loggers store the messages in Entry structs which make it non-trivial to implement the basic println functionality.

The benefit of outputting everything through the abstraction is that for the more exotic platforms, we would only need to implement a custom logger using whatever printing facilities are available and then everything would be runnable out of the box.

[elfenpiff]

@orecham I agree with your approach. So in essence we would have a "log message" without log-level - maybe something just like log_println!("Hello World")

@elBoberido what do you think?

[elBoberido]

The issue is that a logger and the application output are two totally different use cases. It just happens that by default our logger also outputs to the terminal, like what we want our examples to do. Coupling this is not a good idea, for the reasons I mentioned above.

Having the same mechanism to get the characters to the terminal is fine but it should not use the same higher layers of the logger, e. g. to redirect everything to a file if the logger backend is changed.

Ideally, it would also use stdout instead of stderr, like the logger

[elfenpiff]

Then let's phrase it differently. We should provide a customizable output mechanism with a frontend and a backend to output things. The frontend would be something like log_println! but with a better name, maybe iox2_println!()/iox2_eprintln!(), and the backend would be by default stdout/stderr, but when this is not available, the user can provide a custom backend, like for the logger.

[elfenpiff]

From the mechanism and architecture, it would be nearly identical to the logger, just named differently since the semantics/context is different. So it makes sense to put it into the log crate or somehow near to the log crate and maybe have a common abstraction for the log and the upcoming output crate.

[orecham]

@elfenpiff @elBoberido Updated the issue to reflect the conclusion of the above discussion.