Make SignalHandling supports different printer

[z0ow]

The backward::SignalHandling only supports outputting traces via backward::Printer takes a disadvantage to designers to customize their output style. This PR makes a derived class of backward::Printer can override print functions and adds class backward::SignalHandlingBase to allow designers to set their inherited printer as default.

The std::shared_ptr is brought into backward::SignalHandling to support polymorphism. This feature could make backward better if this change does not affect performance and compatibility. 🙏

[nmaludy]

+1 would like to see this merged, i had a similar problem trying to customize the formatting of the SignalHandler output

[Trafo]

me too

[bombela]

In this current state this would break backward compatibility by requiring C++11. So at least a new major version release would be required. But it is surely possible to maintain compatibility.

The printer and signal handlers were meant to be examples to use as a starting point for your own customization. You can write your own, specific to your project(s) and use what you want from backward-cpp.

With insight I should have had those examples in a different file. I wanted backward-cpp to be a single file to copy around for easy installation.

With that said, many people have asked for this feature over time. Maybe we can have our cake and eat it too.

[giacomocaironi]

Any updates?
I was able to create a custom SignalHandling class, but to achieve this I had to copy more than 300 lines of code from the example. If only we could inherit from the base class and override the functions this could be achieved in only a few lines of code.

[bombela]

Why can't you inherit and override the base class?

[giacomocaironi]

I tried inheriting from the base class and overriding only handleSignal (I'm on linux), and it didn't change anything. I had to copy also the constructor which in turn needed some private methods. I think this is because the function in not marked as virtual in the base class, but I am not very familiar with c++ so I could be completely wrong.

Anyway my objection remains, if the PR could be merged it would simplify customizing the printer a lot. I understand that SignalHandling was only meant as an example, but it implements a lot of things, reusing it would be nice

[bombela]

Dah; of course; the vtable is missing! In C++ the vtable pointer is within the object and I somehow forgot about that (I blame it on enjoying Rust too much ;)). I now remember that the destructor must be marked virtual too.

Instead of SignalHandlingBase::set_printer<Printer>() what about SignalHandling<P>(P&& printer)? That is, the signalhandling is given a Printer object to consume. Instead of setting a pointer to a printer. It somehow strikes me as being harder to misuse. It means you cannot modify the Printer after the fact. But maybe this is a good thing?