C++ write your own stream class - part 1: output stream initial design (embedded friendly C++)

RE: C++ write your own stream class - part 1: output stream initial design (embedded friendly C++)

Jan Cumps — Sat, 15 Nov 2025 15:00:58 GMT

a real world example. Implementation for a Raspberry Pico. Using its UART api:

Code:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:a562dd8b-d276-4ce2-9069-2f6f482f7585:type=csharp&text=class%20uartostream%20%7B%0Apublic%3A%0A%20%20%20%20uartostream%28%29%20%7B%7D%0A%0A%20%20%20%20uartostream%26%20operator%20%3C%3C%20%28const%20char%2A%20msg%29%20%7B%0A%20%20%20%20%20%20%20%20uart_puts%28UART_ID%2C%20msg%29%3B%0A%20%20%20%20%20%20%20%20return%20%2Athis%3B%0A%20%20%20%20%7D%0A%0A%20%20%20%20uartostream%26%20operator%20%3C%3C%20%28const%20std%3A%3Astring%26%20msg%29%20%7B%0A%20%20%20%20%20%20%20%20uart_puts%28UART_ID%2C%20msg.c_str%28%29%29%3B%0A%20%20%20%20%20%20%20%20return%20%2Athis%3B%0A%20%20%20%20%7D%0A%7D%3B]

RE: C++ write your own stream class - part 1: output stream initial design (embedded friendly C++)

Jan Cumps — Wed, 12 Nov 2025 17:14:31 GMT

Is this expensive? The facts

When I use a subclass uartiostream and its << operator:

This compiles to

main:
        mov     r3, #53
        mov     r0, #0
        sub     sp, sp, #8
        strb    r3, [sp, #7]
        add     sp, sp, #8
        bx      lr
u:
        .space  1

when I use plain C to do the same:

main:

        mov     r3, #53
        mov     r0, #0
        sub     sp, sp, #8
        strb    r3, [sp, #7]
        add     sp, sp, #8
        bx      lr

The only difference is a single address location (32 bits) to hold the object u

0 cpu cycles

That's virtually cost-free

RE: C++ write your own stream class - part 1: output stream initial design (embedded friendly C++)

DAB — Tue, 11 Nov 2025 20:37:34 GMT

Nice post Jan.

RE: C++ write your own stream class - part 1: output stream initial design (embedded friendly C++)

Jan Cumps — Tue, 11 Nov 2025 20:26:39 GMT

Defining an input streamer has the same complexity as the output streamer.

Once the in- and out-streamers are written, writing a bidirectional one isn't that difficult:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:cc081195-6eb2-4329-af2e-fb1d07d62d54:type=csharp&text=class%20uartistream%20%7B%0D%0Apublic%3A%0D%0A%20%20uartistream%28%29%20%7B%7D%0D%0A%20%20%0D%0A%20%20uartistream%26%20operator%20%3E%3E%20%28std%3A%3Astring%26%20msg%29%20%7B%0D%0A%20%20%20%20%2F%2F%20read%20from%20UART%0D%0A%20%20%20%20return%20%2Athis%3B%0D%0A%20%20%7D%20%20%0D%0A%20%20uartistream%26%20operator%20%3E%3E%20%28char%2A%20msg%29%20%7B%0D%0A%20%20%20%20%20%20%2F%2F%20read%20from%20UART%0D%0A%20%20%20%20return%20%2Athis%3B%0D%0A%20%20%7D%0D%0A%7D%3B%0D%0A%0D%0Aclass%20uartiostream%3A%20public%20uartistream%2C%20public%20uartostream%20%7B%0D%0A%7D%3B]

Inheriting form both base classes doesn't cost anything - because I didn't define any virtual functions.

The difficult work will be at the lower level: write the implementation of the << and >> operators using device dependent UART APIs.