c++ The Mithycal Console App

Why hiding it, I like this diagram. A lot. It represents a typical “cloud side” (Azure) system using some component called “XYZ”, that happens to be written in C or C++. Most likely C, because it must be integrated with NODE.JS.

Spot your product
Spot your product

You are C/C++ coder/developer/owner (of XYZ) and this is where your component lives these days (2020 Q1). Or in a place much like this one but on a different cloud.

Right now, when you write these numerous console apps, liberally sprinkled with numerous printfs() even mixed with std::cout you need to have this picture in mind, before shipping your favorite library, little server or whatever else, including your clever, color-coded, terminal diagnostic output. And here is the point.

Your console output is only plain redundant

Nobody will ever see it, or care to look at it. Typical small-ish data centre these days has approx. ten thousand VM-s. Do you expect admins to try and find a few of them where your console app is outputting critical information?

Datacenter admins are extraordinarily complex personalities. Do not ask them to pay special attention to you. Even their paymasters are careful not to. So, do not take it personally.

But (I hear you say), this is just one library! Yes, it is, but (alas) you have sold it. You are now paid, and contract bound. You have made a code change, upon a change, upon a change, as requested by paying customers.  Often overnight or over a weekend.  Or even on board a plane.

And doing so, you had no choice but to leave inside exactly what you are not supposed to: a lot of console output. Your thinking is: this is for users/admins, of course, since you have this brilliant debugger that “everyone is using” for developers.

A word of serious golden advice: Never ever mention “debugger that everyone is using” to any of the data center admins.

You will be let into the data centre, in the first place, only if some fundamental problem has happened with the production VM’s. Yes, you will be summoned, and you will oblige because this is what the contract says. Just sit tight and quiet and hope nobody will ask you anything.  Because if they do the first question is:

“Where is your diagnostic output?”

And this is the moment when C++ boys turn into the men. At this moment the last thing you want to say is: “Well we are using this brilliant simple and useful coloured terminal output. Can we please connect to it?”

The entire world of a difference in your life, the real turning point in your career, turning for the better, will come if you instead say: “Well the log files are at … “. Cue to sudden cheering. Very good boy, file logs, good!

But! You are not a “boy”, you are “one of them, the team player, the guy to turn to when the proverbial hits the fan”; just if you say instead (casually and relaxed): “Well it is going to the Syslog, of course”.

Syslog is optional. But you had better use it and do not think of it as “optional”. Syslog is not used just for network devices monitoring. That is what it was invented for decades ago. These days, it is used (and it will stay) also as a simple, fast, resilient, mature application logging protocol and system. There is no data center not using Syslog.

Syslog and you
Syslog and you (hint: you are not in the picture, things with a plus prefix are your devenv situation)

Am I making myself clear here? Good. That was the “why”. Let’s proceed with the “how”.

Never do anything unless you have your logging ready first

However small and insignificant (you might think) your code is. But I can hear from you again (did I not tell you to be quiet?): “…I will surely not use Syslog server(s) when developing on my laptop, mobile phone, smartwatch, IoT coffee maker?! ..” (Or whatever you fancy these days.)

Of course, you will not. (I do by the way) All I am kindly asking you to do is to make your life much simpler and never (ever) use directly either <stdio.h> or <iostream> in your code. Ever Again.

Decouple from output libraries

Simple C++ will take you extremely far from terminal/console output libraries, just if you want to. Here is what we use, and how it looks:

Our development default (Not a production! ) Is to have console output with the second resolution time stamp, prefixing each line. If required one can switch to showing nanoseconds in a timestamp:

Crucially, by using the set_sink_function we can change where the final output goes to.

Next, we switch to our Syslog client and proceed as before.

We first switch off the time stamp we generate, then we redirect to our local syslog lib, and the whole of our code suddenly sends proper Syslog messages.

If and when we need to redirect every output back to the console we simply do:

Obviously with the sink_function users are decoupled from the output of choice: console, file, Syslog, etc.

Here is the Syslog Watcher, server GUI, for data center admins, in action.

Syslog server console. Nice and useful isn't it?
Syslog Watcher, server console. Nice and useful, isn’t it?

Lastly, the GUI

This way, your library is server-side admin friendly. But also, the GUI app is friendly. Even if it is used on the client-side (read: local pc or laptop) from some GUI based customer app of yours, it will output useful logs, not to the non-existent console.

This post has provoked a lot of interest, so I just managed to generate even more workload. In the next part of this post, I will be presenting the consolidated github repository where the code we are talking about is.

Just say no to the console output.

%d bloggers like this: