• print() can be called withmultiple arguments, e.g. print("Name=", name, " Age=", 42); will be equivalent to print("Name="); print(name); print(" Age="); print(42);
  
• println() can be called with multiple arguments, which will be printed as asingle line; e.g. println("Name=", name, " Age=", 42); will be equivalent to print("Name="); print(name); print(" Age="); println(42);
• Both functions return the total number of bytes written (the sum of all subcalls).
• The implementation isbackwards compatible.  Calls such as print(num, HEX) are still supported.  print("0x", 42, 16, "=", 42) will print "0x2A=42".  This is, two numbers in a row are interpreted as (number, base) (or (number, digits) for doubles).  Numbers may still be concatenated like print(n1, "", n2) (although I don't think this would be too useful anyway). (Personally I don't quite like this convention and think a better way to do this would be with print(String(num, HEX)), but I think backwards compatibility is important.  In a future, it would be nice if some sort offormatters are implemented (and in that case I'd pass them as thefirst argument).)
• The templates areinlined, using not only theinline keyword (which was implicit anyway) but also GCC's __attribute__ ((always_inline)).  This makes the variadic call identical to multiple 1-argument calls, so the resulting binaries should be identical to that (otherwise this might create a new function for each way print() is called, which seems a bit crazy).
• This implementation makes heavy use ofC++11 variadic templates, so C++11 support is a must.  (This could be guarded in #if __cplusplus>=201103L, just in case; but I don't think it's necessary as it overcomplicates things.)
  

There are other features that I want todiscuss (I've already implemented them; it's just a matter of whether or not to remove them):

• Inline print for integers (INLINE_PRINT_):  this replaces the calls to print([un]signed char/short/int) with inline calls to print([un]signed long). This reduces the binary size for programs that print both ints and longs, for example; and also simplifies the code in Print.cpp.  Additionally, it adds explicit support for signed char (≠char), [un]signed short, and float.  I ran some tests on some random sketches I found on internet and in all cases the executable size was slightly reduced or equal.
• Inline replace println(...) with print(...); println() (INLINE_PRINTLN_):  this way, println("Age=", 42) becomes print("Age="); print(42); println().  This simplifies Print.cpp a lot, which is good from a maintainability point of view, and potentially reduces the executable size, as it removes a lot of functions from Print.cpp.  (The way it is implementeddepends on C++11 variadic templates, but I think it can be changed so that it doesn't.)
  
• C's printf-like Print::printf() method (SERIAL_PRINTF_):  this method uses <cstdio>'s vsnprintf() to print the result to a local buffer, and then write that.  This is a rather huge function that uses about 1.5 KB of program memory when used, plus it doesn't support Arduino Strings (unless you use the .c_str() method) so it probably won't be too practical, but I guess people used to C may like it.
  
• Serial<< operator (SERIAL_SHIFT_OP_):  this operator allows doing Serial << "Age=" << 42; but it doesn't allow "formatters" of any kind (HEX, digits...).  It's there for people used to C++'s cout.  There's no `endl` so far; one would have to do <<"\r\n" explicitly for that.
  

Attached you'll find the Print.h file, which has macro definitions at the beginning that can be commented out to disable individual features; as well as the Print.cpp file (for AVR, not SAM).  These macros and all the #ifdef would be removed on the final code I put on the PR.

What do you think?  Any opinions on which features should or shouldn't go here, or any other comment?  I think this could improve the user experience considerably.

Serial.println("sensor 1: " + sensorOne + "\tsensor 2: " + sensorTwo);

Gabriel,
What you propose is very limited and requires modification for every individual usage case. IMO, it is not a good solution.
There are much better ways to get xxprintf() style formatted output within the C++ Arduino environment.
For example using the power of C++ and the Arduino Print class it is reallytrivial to make a function that works like fprintf() but uses Print class objects.
Here is the code for a simple function called Printf() that works just like fprintf() but uses a Print class object instead of a FILE pointer.

size_t Pprintf(Print &outdev, const char *format, ...)
{
char buf[128];
    va_list ap;
    va_start(ap, format);
    vsnprintf(buf, sizeof(buf), format, ap);
    va_end(ap);
    return(outdev.write(buf));
}

This function would will work with any object that uses the Print class, which includes pretty much any Serial, LCD, GLCD,  LED matrix libraries, etc..
Essentially, anything that currently supports print() will work with the Pprintf() function above.

and here is a working sketch that demonstrates how to use it with the Serial object.

void setup(void)
{
    Serial.begin(115200);
    Pprintf(Serial, "Pprintf...\n");
}
void loop(void)
{
    Pprintf(Serial, "Seconds up: %04ld\n", millis()/1000);
    delay(1000);
}

size_t Pprintf(Print &outdev, const char *format, ...)
{
char buf[128];
    va_list ap;
    va_start(ap, format);
    vsnprintf(buf, sizeof(buf), format, ap);
    va_end(ap);
    return(outdev.write(buf));
}

And here is a bit of rant on the topic of the Arduino Print class.

From a larger perspective, IMO, the only reason not to have a printf() method built into the bundled Print class provided by the Arduino IDE is obstinance on the part of certain key Arduino developers. Yeah I know that is a pretty harsh assessment, but that is my opinion.
At this point in time, the xxprintf() formatting routines have existed for 50 years.
They are very well documented and understood and examples on how the formatting string works are literally everywhere.
Many people have been asking for it on Arduino for many years.
This playground page has existing for around 6 years:https://playground.arduino.cc/main/printf
Also, several 3rd party cores have already added a printf() method to their Print class. Cores like Teensy/Teensy3, Chipkit, and ESP.
Even if very green/newbie Arduino users find it complicated or too complex for them, they don't have to use it and it won't eat up any code space in their images.
But in reality with a small bit of coaching and a bit of googling, I believe that even a newbie should be able to easily figure out how to use it.

So at this point in time, I really don't understand why there is still so much resistance to adding a printf() method to the Print class.

--- bill

--

I seem to recall there was a language that had print formats in the form of an even more specific template than printf - something like nnnnn.nn. I forget what it was. A quick scan of Python, Pascal and several FORTRANS didn't find it but did confirm that there is nothing in common use  that's better than printf. Just  messier ones.

--

To view this discussion on the web visithttps://groups.google.com/a/arduino.cc/d/msgid/developers/CAH1-q0hNsssYOAM%3DZEej471hJOKtjAOL5DhTQdpSM7mHUkpCtA%40mail.gmail.com.

To view this discussion on the web visithttps://groups.google.com/a/arduino.cc/d/msgid/developers/067BEFA0688749578132D845346329E6%40JohnDoughPC.