ArduinoCore-API icon indicating copy to clipboard operation
ArduinoCore-API copied to clipboard

Introduce variadic print

Open facchinm opened this issue 6 years ago • 12 comments

based on https://github.com/arduino/Arduino/pull/5829

facchinm avatar Mar 22 '19 17:03 facchinm

@facchinm, I also still have a version of this, including extended formatting, lying around that I need to finish up and document. If you're thinking on adding this, I could see if I can find some time soon to share that.

matthijskooijman avatar Mar 22 '19 17:03 matthijskooijman

No hurry, take your time, I just posted it here to avoid losing all the tracks due to repo changes and issues being closed on the IDE repo

facchinm avatar Mar 25 '19 08:03 facchinm

Is there anything you need from me? (It's been ages and I don't quite remember the code but I guess it won't be that hard)

cousteaulecommandant avatar Jun 02 '19 00:06 cousteaulecommandant

I mostly need some time to clean things up and document things. Also, I'm not entirely sure that I'm happy with, the way variadic formatting can be customized right now (it does what it should, but it isn't entirely easy to customize things). Perhaps I should dig into that, document how it works now and we can have some discussion about how to improve on that...

matthijskooijman avatar Jun 03 '19 10:06 matthijskooijman

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain? I feel the same way, but can't think of a better approach that doesn't break backwards compatibility. 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.

cousteaulecommandant avatar Jun 16 '19 13:06 cousteaulecommandant

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain?

No, that is actually quite fenced off (only needs to be supported as the first two arguments).

What I mean is that in my code I have some ways to provide custom formatters and formatting objects, but that's a bit unwieldy to use (which also impacts the default formatting options, since those are just built-in custom formatters and options).

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.

I suspect this would mean that specifying formatting becomes more clunky, or more likely, significantly less efficient (having to construct intermediate objects and formatted values rather than writing them to a stream directly). Not entirely sure, though.

Also, this would cause a disconnect between the currently supported formatting options (base and precision) and any newly added options in terms of syntax.

matthijskooijman avatar Jun 16 '19 14:06 matthijskooijman

@cousteaulecommandant, I created #34 for further discussion about formatting, since this is not strictly related to this PR.

matthijskooijman avatar Jun 16 '19 14:06 matthijskooijman

We need this one 😍

ubidefeo avatar Jul 15 '19 12:07 ubidefeo

Do you mean how the whole "two consecutive integers are interpreted as value + formatting" approach is extremely odd and hard to maintain?

No, that is actually quite fenced off (only needs to be supported as the first two arguments).

Why? I think it's perfectly reasonable to expect that Serial.println("var: 0x", var, 16) prints in hex.

szeder avatar Jul 16 '19 10:07 szeder

Why? I think it's perfectly reasonable to expect that Serial.println("var: 0x", var, 16) prints in hex.

Don't worry, that's still supported. print("var: 0x", var, 16) will print "var: 0x" and then call print with the rest of the arguments (i.e., print(var, 16)), so we only need to care about the case for two leading numbers.

I was referring to the fact that it is a bit artificial that print("foo", "bar") prints foobar but print(16, 16) prints 10 and not 1616. (The feature makes sense and it's easy to document, just tell users not to print two consecutive integers and use print(16, "", 16) instead if they really want to concatenate integers; my concern was that the implementation was kind of messy.)

cousteaulecommandant avatar Feb 27 '20 23:02 cousteaulecommandant

CLA assistant check
All committers have signed the CLA.

CLAassistant avatar Apr 09 '21 13:04 CLAassistant