You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past, there has been talk of improving print formatting. e.g. on the mailinglist here, here, here. The bottom line is that there is a need for a way to have more control over print formatting (e.g. leading zeroes) and, IMHO, also ways to apply custom formatting and formatting options.
Note that printf is often suggested as the solution to this need. In the above threads, a lot of the discussion is about his, but there are IMHO sufficient reasons to not want to use printf (which I'll not repeat here). Please do not add comments here arguing for printf support. Instead, head over to #28 and #32 if you want to make a case for printf.
A related request is to allow printing multiple values in a single print call (e.g. to do things like "Serial.println("Received ", num, " bytes");`).
PR #30 has an implementation for this.
IMHO it would be good to tackle formatting options at the same time as variadic printing, since the implementations are likely related (and doing one without the other might cause compatibility problems in the future).
In the above discussions, I've suggested an approach where printable arguments can be intermixed with formatting directives, putting the formatting after the value (just like the current base and precision arguments). These formatting directives could then be either builtin-directives, or custom directives. For my previous thoughts, see here and here. Since people seemed to like this approach, I did an initial implementation.
I still have a lot of documentation to do, and I'm not quite happy with the way that formatter customization works now, but in the interest of discussion, I've pushed my changes here: https://github.com/arduino/ArduinoCore-avr/blob/formatting/cores/arduino/Print.h For an example sketch that uses this, see https://gist.github.com/matthijskooijman/cbac69e8db907ab0f849775b5a1cac44. Note that this is just the sketch I was using during development, so it's not so much a realistic testcase as well as a way to make sure various things would (not) work. I'm not actually sure if any of this even compiles currently, it's been a while since I worked on this.
Maybe it'd be better to move formatting entirely out of Print.h (except for very simple things, for the sake of backwards compatibility) to a separate "value formatter" class that does all the formatting work, and leave Print::print for simple multi-argument printing.
This might be an interesting avenue to explore. It would mean that (custom/extended) formatting would work differently than the current base/precision formatting options, but if we come up with something significantly better, I guess deprecating the existing system and switching to something new would be ok. Implementing this might very well be simpler than what I did so far (it might even be a matter of creating custom Printable instances, though I suspect there might be some performance issues with that approach).
I have no time right now to go into this further, but wanted to at least create this issue as a place to collect further discussion.
The text was updated successfully, but these errors were encountered:
In the past, there has been talk of improving print formatting. e.g. on the mailinglist here, here, here. The bottom line is that there is a need for a way to have more control over print formatting (e.g. leading zeroes) and, IMHO, also ways to apply custom formatting and formatting options.
Note that printf is often suggested as the solution to this need. In the above threads, a lot of the discussion is about his, but there are IMHO sufficient reasons to not want to use printf (which I'll not repeat here). Please do not add comments here arguing for printf support. Instead, head over to #28 and #32 if you want to make a case for printf.
A related request is to allow printing multiple values in a single print call (e.g. to do things like "Serial.println("Received ", num, " bytes");`).
PR #30 has an implementation for this.
IMHO it would be good to tackle formatting options at the same time as variadic printing, since the implementations are likely related (and doing one without the other might cause compatibility problems in the future).
In the above discussions, I've suggested an approach where printable arguments can be intermixed with formatting directives, putting the formatting after the value (just like the current base and precision arguments). These formatting directives could then be either builtin-directives, or custom directives. For my previous thoughts, see here and here. Since people seemed to like this approach, I did an initial implementation.
I still have a lot of documentation to do, and I'm not quite happy with the way that formatter customization works now, but in the interest of discussion, I've pushed my changes here: https://github.com/arduino/ArduinoCore-avr/blob/formatting/cores/arduino/Print.h For an example sketch that uses this, see https://gist.github.com/matthijskooijman/cbac69e8db907ab0f849775b5a1cac44. Note that this is just the sketch I was using during development, so it's not so much a realistic testcase as well as a way to make sure various things would (not) work. I'm not actually sure if any of this even compiles currently, it's been a while since I worked on this.
In #30, @cousteaulecommandant said:
This might be an interesting avenue to explore. It would mean that (custom/extended) formatting would work differently than the current base/precision formatting options, but if we come up with something significantly better, I guess deprecating the existing system and switching to something new would be ok. Implementing this might very well be simpler than what I did so far (it might even be a matter of creating custom
Printable
instances, though I suspect there might be some performance issues with that approach).I have no time right now to go into this further, but wanted to at least create this issue as a place to collect further discussion.
The text was updated successfully, but these errors were encountered: