Print Class Reference

Inheritance diagram for Print:

Public Member Functions
virtual size_t	write (uint8_t c)=0
virtual size_t	write (const uint8_t *buf, size_t n)
size_t	write (const char *s)
size_t	print (char c)
size_t	print (const char *s)
size_t	print (const String &s)
size_t	print (int n, int base=10)
size_t	print (long n, int base=10)
size_t	print (unsigned long n, int base=10)
size_t	print (double v, int digits=2)
size_t	println ()
size_t	println (char c)
size_t	println (const char *s)
size_t	println (const String &s)
size_t	println (int n, int base=10)
size_t	println (long n, int base=10)
size_t	println (unsigned long n, int base=10)
size_t	println (double v, int digits=2)
size_t	printf (const char *fmt,...) CHECKPRINTF_pos2

Detailed Description

MOVED HERE, and it must stay below this point: Print uses String (typedef at typedef LL_String String above) and CHECKPRINTF_pos2 (defined just above). Declared any earlier in this header and the compiler reports "String does not name a type" – which is a header-ordering error, not a missing class.

GUARDED, AND IT MUST BE. On ESP32 the VENDOR Arduino core defines its own Print and Stream (cores/esp32/Print.h, Stream.h) via Arduino.h, so declaring these unconditionally is a "redefinition of class Print" build failure on every ESP32 target. It compiled clean on the hosts because there is no Arduino core there to collide with – which is exactly why the mistake was invisible until an ESP32 build ran. When this block was moved down here to sit below the String typedef it left the LL_ARDUINO guard that ends further up; it now carries its own. LLArduino PROVIDES these where the vendor core is absent, and defers to it where present.

LL_ARDUINO Print / Stream / Serial. NOT STUBS, and they need not be: Print and Stream are pure character I/O, and LambStdio ALREADY implements exactly that on POSIX (stdin/stdout in non-canonical mode). So this is an Arduino-SHAPED FACADE over working I/O, in the same class as millis() – genuinely implemented, not simulated. It is what lets sketch-style code (Serial.println("hi")) run on a host with no board, and on WebAssembly and Windows, where Espressif's core cannot go at all.

FIDELITY IS THE RISK HERE, not capability. Arduino's Print has behaviours worth matching DELIBERATELY rather than by accident, and each is a place a host test could pass while the device disagrees: println() terminates CRLF ("\r\n") not "\n"; write() returns a BYTE COUNT; print(double, digits) defaults to 2 decimal places; print(int, base) supports BIN/OCT/DEC/HEX. Those are exactly what success criterion 3 exists to check – the same suite run against the vendor core and against LLArduino must agree.

Member Function Documentation

write()

virtual size_t Print::write ( uint8_t c )

pure virtual

Implemented in LLArduinoBufPrint.