Binary logging framework in C++ [closed]

Question

There are a lot of logging frameworks for many languages out there. But I did not find any framework suitable for certain embedded applications. I want to log data in an embedded device and neither have a lot of bandwith or a lot of memory available.

The logging framwork I want should be usable like usual logging frameworks with descriptive strings etc. directly inside the source code. I would like to extract the descriptive strings from the source code to a seperate file (e.g. xml) and replace them in the binary output with ids. In an analysis tool, i would then take these IDs and display the text again. For PC debugging I could directly use the string.

I want to know about feasible methods to provide message id's, formatting instructions and accompanied parameter values, but put to the communication port in kind of a compact binary format.

Also I'd like to avoid seeing the footprint blowup with c++, introduced by

#include <iostream>

or

#include <stdio.h>

et. al like with the standard c libraries type formatting libraries.

Answer 1

Does anyone know how to easily extract strings from source code and replace them with unique ids for binary output?

Well I think you want to log your devices something like a error message id and pass some certainly known parameter values along, to be formatted as well human readable text at the client's side.

E.g. using google protobuf along with custom options for such protocol should be appropriate:

message DebugLogMessage {
   extensions 4 to max;
}

message SystemStateLogMessage {
    option render_format = "System temp: %d, Restarts: %d";
    extend DebugLogMessage {
        optional SystemStateLogMessage bar = 126;
    }
    optional int64 temp;
    optional int16 restarts;
}

The render_format option is meant to be used at the client site solely. On the small target you'll only need to provide the current values.

To provide the data parameters from a small embedded system, Nanopb establishes a good binding for c language, while preserving a reasonably small footprint.

NOTE
That's just a rough idea sketching out what I think you'll need. I hope you can catch the abstraction. I'm not saying that this is the only viable way, to realize what I understood you want to have, neither I'm going to give you production ready code.