"\n" creates a new line, but also adds spaces. about modm HOT 11 CLOSED

Meh, looking through some other discussion on std::endl ([1], [2], [3]) I'd just leave our implementation just as it is.

Instead I want to focus on adding all or parts of {fmt} to modm.

from modm.

I'm experimenting with modm and ran into this running my first example. In the last five minutes my opinion has flip flopped back and forth twice. I agree with what's been said above and the conclusion. A couple of things stick in my mind, however...

One of those discussions points out that standard C++ will tailor the endl behavior depending on what operating system you're running on, adopting the standard of the platform. These days that's basically either \n or \r\n, although long ago apparently Macs used \r. I don't know if modm swaps newline endings when running on Windows or not -- I haven't tried to tackle running it on Windows (yet), just focusing on Linux, MacOS, and WSL. Eventually I'll need to dig into Windows, because my client runs all Windows machines.

The problem comes up when you cross compile and the target doesn't match the build platform. In embedded systems, my area of interest for applying modm, this is true 99% of the time. And furthermore, these is no "standard platform" was of handling newlines in embedded applications, where you might be using ostream to send data for all kinds of different reasons -- an embedded file system, and interfaces whose format is beyond your control and has fixed newline requirements (NMEA for example).

I'm so new at modm I have no idea how difficult any such change would be if warranted. It does seem to me that this is something best left to the application, as noted above. There's just no reasonable choice you could make even if you wanted to, at least in the case of most embedded applications. Changing your terminal settings works great if you're using a terminal emulator, less so if you're using a real terminal or even a dumb dot-matrix printer for logging.

For now, in my code, I'm just going to not use endl and use a macro or static const to define an application-wide NEWLINE variable. And for the record, I lean towards the Unix camp's line-feed-only as the newline character for almost everything. But when sending to a terminal, without something in the middle like termcap, you're on your own and have to consider these things.

And so far, I'm really liking this framework as it applies to embedded projects.

from modm.

It needs to be "\r\n"

from modm.

\n is the line feed character, it only shifts the line one down. \r is the carriage return, it moves the cursor back to the beginning of the line.
We could make modm::endl configurable via a lbuild option to map it to \r\n (by default) or \n if so desired.

What are your opinions on this?
cc @rleh @dergraaf @chris-durand

from modm.

You can configure your terminal to map \n to \r\n, at least that‘s what I do with picocom.

from modm.

std::endl

template< class CharT, class Traits >
std::basic_ostream<CharT, traits>&endl(std::basic_ostream<CharT, Traits>& os );

Inserts a newline character into the output sequence os and flushes it as if by calling os.put(os.widen('\n')) followed by os.flush().

This is an output-only I/O manipulator, it may be called with an expression such as out << std::endl for any out of type std::basic_ostream.

From https://en.cppreference.com/w/cpp/io/manip/endl

from modm.

So we would keep the \n by default and optionally allow non-standard \r\n for convenience?

from modm.

I would rather just add instructions on how to properly configure a serial terminal on the PC.

from modm.

@FadiBunni Which serial terminal software did you use?

from modm.

For future reference, I let picocom remap my input like this:

picocom --imap lfcrlf -b 115200 /dev/tty.usbserialXYZ

from modm.

Eh, I'm older now and more pragmatic. We can just make it configurable via lbuild. Then modm only needs to justify the default value, and can just comfortably… delegate all the issues with the host receiver settings to the developer, bwarharhar ;-P

And so far, I'm really liking this framework as it applies to embedded projects.

Thank you!

from modm.