Klassenfrage :)

EL europ

Findet sich hier vielleicht ein Kenner in c++ der mir die einfachste Klasse "_Display" mit ihren drei kleinen Methoden in sauberem c++ darlegen kann, als minimal-Bsp-Code in Betracht ihrer Beziehung Colorinterface->Apple->userinterface->Display. Dann kann ich den Rest nach diesem Muster neu gestalten. Sonst muss ich durch den "Wolf" weil mir grad die Mittel fehlen für ein neues Fachbuch

wob

@EL-europ sagte in Klassenfrage :

@Finnegan
Verstehe ich das richtig, das -fsanitize mir Meldungen(Abstürze) erst zur laufzeit "verursacht" ?
Ah blöde Frage, eben seh ich das er es gar nicht kompiliert mit diesem Flag

Ja, die sanitize-Optionen sind zur Laufzeit.

Versuchs mal mit clang-tidy oder cppcheck (wobei das Herumdoktoren an den Symptomen wäre, neu schreiben erscheint hier als plausible Option).

/tmp/mandelbrodt/include/_Apple.cpp:65:66: error: arithmetic on a pointer to void [clang-diagnostic-error]
                        pthread_create( &thrIds[aktThr], NULL, &thrFunc, (void *)tmp_x+aktThr*sizeof(int));
                                                                         ~~~~~~~~~~~~~^
/tmp/mandelbrodt/include/_Apple.cpp:149:2: warning: 'sprintf' will always overflow; destination buffer has size 17, but format string expands to at least 18 [clang-diagnostic-fortify-source]
        sprintf(iterText, "I-Werte % 8d", countsOfIter);
        ^
/tmp/mandelbrodt/include/_Apple.cpp:171:3: warning: 'sprintf' will always overflow; destination buffer has size 16, but format string expands to at least 18 [clang-diagnostic-fortify-source]
                sprintf(text[5], "Itr2= % 10d", iterMembers[countsOfIter-2][0]);
                ^
/tmp/mandelbrodt/include/_Colorinterface.cpp:53:2: warning: 'sprintf' will always overflow; destination buffer has size 8, but format string expands to at least 9 [clang-diagnostic-fortify-source]
        sprintf(text,"%- 7d",id);
        ^
/tmp/mandelbrodt/include/_Colorinterface.cpp:55:2: warning: 'sprintf' will always overflow; destination buffer has size 8, but format string expands to at least 9 [clang-diagnostic-fortify-source]
        sprintf(text2,"%- 7d",satzcount);
        ^
/tmp/mandelbrodt/include/_Colorinterface.cpp:88:2: warning: 'sprintf' will always overflow; destination buffer has size 9, but format string expands to at least 10 [clang-diagnostic-fortify-source]
        sprintf(text,"% 8d",elements.at(apos).id);
        ^
/tmp/mandelbrodt/include/_Colorinterface.cpp:102:2: warning: 'sprintf' will always overflow; destination buffer has size 9, but format string expands to at least 10 [clang-diagnostic-fortify-source]
        sprintf(text2,"% 8d",members);
        ^
/tmp/mandelbrodt/include/_Colorinterface.cpp:245:63: error: non-constant-expression cannot be narrowed from type 'unsigned long' to 'int' in initializer list [clang-diagnostic-c++11-narrowing]
        struct _farbe farbe2{elements.at((elements.size()-1)).color, (elements.size()-1)};
                                                                     ^~~~~~~~~~~~~~~~~~~
/tmp/mandelbrodt/include/_Colorinterface.cpp:245:63: note: insert an explicit cast to silence this issue
        struct _farbe farbe2{elements.at((elements.size()-1)).color, (elements.size()-1)};
                                                                     ^~~~~~~~~~~~~~~~~~~
                                                                     static_cast<int>(  )
/tmp/mandelbrodt/include/_Userinterface.cpp:135:2: warning: 'sprintf' will always overflow; destination buffer has size 30, but format string expands to at least 31 [clang-diagnostic-fortify-source]
        sprintf(text[1], "i = %.24f", i);
        ^
/tmp/mandelbrodt/include/_Userinterface.cpp:152:33: warning: 'sprintf' will always overflow; destination buffer has size 8, but format string expands to at least 10 [clang-diagnostic-fortify-source]
        if(element < 2 || element > 5) sprintf(text, "% 8d", (int)elements.at(element).wert);
                                       ^
/tmp/mandelbrodt/include/graphics/font8x8.h:67:25: error: constant expression evaluates to 255 which cannot be narrowed to type 'char' [clang-diagnostic-c++11-narrowing]
    { 0x00, 0x66, 0x3C, 0xFF, 0x3C, 0x66, 0x00, 0x00},   // U+002A (*)
                        ^~~~
/tmp/mandelbrodt/include/graphics/font8x8.h:67:25: note: insert an explicit cast to silence this issue
    { 0x00, 0x66, 0x3C, 0xFF, 0x3C, 0x66, 0x00, 0x00},   // U+002A (*)
                        ^~~~
                        static_cast<char>( )
/tmp/mandelbrodt/include/graphics/font8x8.h:120:49: error: constant expression evaluates to 255 which cannot be narrowed to type 'char' [clang-diagnostic-c++11-narrowing]
    { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF},   // U+005F (_)
                                                ^~~~
/tmp/mandelbrodt/include/graphics/font8x8.h:120:49: note: insert an explicit cast to silence this issue
    { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF},   // U+005F (_)
                                                ^~~~
                                                static_cast<char>( )

PS: Warum checkst du die compilierte Datei mit ins Repo ein?

EL europ

Ich nutz das git "nur" als Backup, bei mir sterben die usb sticks, sd-karten und andere speichermeiden manchmal.
Die erste compiler meldung bekomm ich auch (ohne die sanitizer) und bedeuted nur das er die Größe/Breite des Integerwertes, der zur Adresse addiert wird zur compileZeit nicht kennt. Das sit kein Problem meines erachtens in c, in c++ ist es vielleicht ein prop?
Die zweite meldung interpretiere ich so, das er den Rest des Strings einfach abschneidet? Aber lass mich belehren und werde die c++ Version std::format nutzen müssen.
Die Folgende Meldung "narrowed from type 'unsigned long'": bedeuted (vermute ich) nur das ein Long Int zu Int verengt wird, das "prob" umgehe ich in dem ich nur Werte bis 9999999 im prog zulasse

Die nächste Meldung welche die char-Fontarrays betrifft: Wäre es besser den Typ uint8_t zu nehmem? Nur weiss ich grad net obs dann props mit Funktionen auf ihnen gibt.

Schlangenmensch

Gerade die Display ist undankbar, weil System abhängig. Ich sitze z.B. gerade an einem Windows Rechner und probiere zumindest gerne aus, ob das funktioniert

Ich versuche mal ein bisschen was, anhand der mandel.cpp zu erklären.

#define BORDER 2

hier würde man in modernem C++

constexpr unsigned int 2

nehmen. Der Vorteil zur Preprozessor Ersetzung ist, dass das typsicher ist.

_Display *Display;
_Userinterface *Ui;
_Apple *Apple;
_Colorinterface *Ci;

Wie schon mehrfach geschrieben, globale Variablen nutzt man nicht. Da weiß man nie genau welche in welchem Zustand ist. Da definieren, wo sie gebraucht werden und u.a. als Parameter weiter reichen.

in _AppleData sind ein paar Member nicht default initialisiert, besser

struct _AppleData{
	int xpos{};
	int ypos{};
	int width{};
	int height{};
	int xres{1920};
	int yres{1080};
	long double rmin{-1};
	long double rmax{2};
	long double imin{-1};
	long double imax{1};
	int depth{100};
};

std::vector<struct _AppleData> myApples;

das Wort struct brauchst du hier nicht. MIt struct und class definierst du Typen, das hier reicht:

std::vector<_AppleData> myApples;

Das hier

int aktApple = 0;

ist irgendwie der Index nach dem letzten Element in myApples. Das brauchst du nicht, ein std::vector kapselt alles, was du für den Umgang damit benötigen könntest.

Dein _Apple scheint teilweise die gleichen Member zu haben, wie _AppleData. Gib _Apple doch einen Member _AppleData appleData stattdessen und eine Funktion

_AppleData _Apple::GetAppleData()
{
   return appleData;
}

Jetzt wird es wild

void newApple(){
		myApples.push_back(*new _AppleData);

new _AppleData erzeugt einen _AppleData auf dem Heap und gibt einen Pointer darauf zurück. Den dereferenzierst du mit * und rufst über push_back impliziet den Copy Ctor auf. Du merkst die aber den Pointer nicht, der auf den Heap zeigt und kannst den Speicher gar nicht mehr freigeben.

Wenn du es so behalten möchtest, wie du es gerade hast, einfach:

void newApple(){
		myApples.push_back(_AppleData());

Wenn du den vorgeschlagenen Getter von mir implementiert hast:

void newApple(){
		myApples.push_back(Apple->GetAppleData());
}

und die Funktion ist fertig.

Hier

void ui_callback(int i){
	if(i<1){
		myApples.at(aktApple-1).xres = Apple->ui->getWert(0);

willst du auf das letzte element von myApples zugreifen.

Ohne Indexzugriff und extra merken von aktApple:

void ui_callback(int i){
	if(i<1){
		myApples.back().xres = Apple->ui->getWert(0);

Das hier:

Apple->xres = myApples.at(aktApple-1).xres;
			Apple->yres = myApples.at(aktApple-1).yres;
			Apple->xpos = myApples.at(aktApple-1).xpos;
			Apple->ypos = myApples.at(aktApple-1).ypos;
			Apple->width = myApples.at(aktApple-1).width;
			Apple->height = myApples.at(aktApple-1).height;
			Apple->rmin = myApples.at(aktApple-1).rmin;
			Apple->rmax = myApples.at(aktApple-1).rmax;
			Apple->imin = myApples.at(aktApple-1).imin;
			Apple->imax = myApples.at(aktApple-1).imax;
			Apple->depth = myApples.at(aktApple-1).depth;

Sieht so aus, als ob du nicht nur einen Getter auf einen _AppleData Member in Apple brauchen könntest, sondern auch einen Setter:

void _Apple::SetAppleData(const _AppleData& data)
{
   appleData = data;
}

Dann fällt das oben in dashier zusammen:

Apple->SetAppleData(myApples.back());

Erstmal als Anregung. Ich muss jetzt noch ein bisschen selbst arbeiten

P.S: Mach die _ vor deinen Typen weg. Die stören doch nur beim Tippen.

EL europ

@Schlangenmensch
Hey danke für deine umfangreichen und detaiillierten Tips, mit denen hab ich nun auch Arbeit

wob

@EL-europ sagte in Klassenfrage :

Die erste compiler meldung bekomm ich auch (ohne die sanitizer) und bedeuted nur das er die Größe/Breite des Integerwertes, der zur Adresse addiert wird zur compileZeit nicht kennt. Das sit kein Problem meines erachtens in c, in c++ ist es vielleicht ein prop?

Nein, es ist unklar, was void* für eine Breite hat. Wurde dir oben schon erklärt. Siehe auch https://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c

Die zweite meldung interpretiere ich so, das er den Rest des Strings einfach abschneidet?

Wieder falsch. Es wird nicht magisch passend zurechtgekürzt. Es wird Speicher überschrieben, der dir (bzw. der Variable) nicht gehört. Undefiniertes Verhalten, alles kann passieren. Das Programm darf abstürzen, falsche Dinge tun etc.

Finnegan

@EL-europ sagte in Klassenfrage :

Jawoll ich bekomm mit deinen flags nen haufen compilermeldungen mit denen ich mich nun auseinander setzten kann. Das -fsanitaze:memory funktioniert bei mir nicht, aber die Anderen werfent einen haufen Meldungen aus. Die versuch ich erst mal zu verstehen. Danke

Ich schrieb, dass -fsanitize=memory nicht von GCC unterstützt wird, nur von Clang. Bei Bedarf einfach mit clang++ statt mit g++ kompilieren. Die sind weitgehend kompatibel und arbeiten bei allen grundlegenden Sachen mit den selben Parametern. Bestimmte Sanitizer kann man aber nicht zusammen verwenden, wie z.B. -fsanitize=address und -fsanitize=memory. Da müsste man das Programm mehrmals durchtesten, einmal mit dem einen und einmal mit dem anderen Sanitizer.

Verstehe ich das richtig, das -fsanitize mir Meldungen(Abstürze) erst zur laufzeit "verursacht" ?

Ja, wie @wob schon erwähnt hat. Oft hängen die Bedingungen, die zu einem Fehler führen, von erst zur Laufzeit bekannten Inputs ab und können nicht sinnvoll während des Kompilierens analysiert werden. Dafür sind die Sanitizer da. Für statische Analyse (Probleme nur anhand des Codes erkennen) gibt es die von @wob erwähnten Tools wie clang-tidy, cppcheck und andere. Es ist nicht verkehrt, die ebenfalls zu verwenden.

Auch den Compiler aufzufordern sehr strikte Warnungen auszugeben und jede Warnung als Fehler zu interpretieren -Wall -Wpedantic -Werror (und eventuell sogar noch -Wextra) kann hilfreich sein, da es einen zwingt, sich zumindest mal mit potentiellen Problemen auseinanderzusetzen. Selbst wenn die Warnungen manchmal unproblematisch sind, wenn man weiss dass diese in ihrem jeweiligen Kontext nicht zu einem Problem führen können (da sollte man sich aber sicher sein).

Ah blöde Frage, eben seh ich das er es gar nicht kompiliert mit diesem Flag

Die Sanitizer werden aber schon untersützt oder? Ich glaube ein aktuelles Debian z.B. hat GCC 12, damit sollte das gehen. Die Version kannst du mit g++ -dumpversion herausfinden.

Ansonsten sehe ich es auch so, dass es wohl besser ist das Progamm weitgehend neu zu schreiben anstatt "an den Symptomen herumzudoktern". Die Sanitizer und die statischen Analysetools sollten dir allerdings helfen, dich auch davon zu überzeugen - oder dich zwingen, das implizit zu tun, wenn du das alles "fixen" willst

EL europ

@Finnegan
ja ich hab den g++ 12.2.0, der kennt auch kein #include <format>
Mit Codeanalyse hab ich mich in solch gefordertem Ausmaß noch nicht beschäftigt, wird wohl Zeit?

EL europ

@wob
Es ist also Zufall das die thread-Funktion den richtigen x-wert bekommt?
Und wie kann man es umsetzen so das es gutes c++ ist?

Finnegan

@EL-europ sagte in Klassenfrage :

@Finnegan
ja ich hab den g++ 12.2.0, der kennt auch kein #include <format>

Features der Standardbibliothek werden mitunter abhängig vom C++-Standard aktiviert, mit dem der Compiler arbeitet. Ich weiss gerade nicht, was der Default-Standard für GCC 12 ist (könnte C++14 sein), aber std::format und den zugehörigen Header gibt es erst ab C++20. Du solltest diesen Explizit mit dem Compiler-Flag -std=c++20 aktivieren. Dann steht dir auch der <format>-Header zur Verfügung.

Edit: Blödsinn, "Text formatting" und damit std::format scheint es laut dieser Support-Matrix tatsächlich erst ab GCC 13 und Clang 17 zu geben. Bei diesen gilt dann aber, was ich oben geschrieben habe. Das ist nur aktiv, wenn der Compiler in dem entsprechenden Sprachstandard arbeitet.

Mit Codeanalyse hab ich mich in solch gefordertem Ausmaß noch nicht beschäftigt, wird wohl Zeit?

Schadet gewiss nicht. Du scheinst da ja auch ein gutes Testprogramm zu haben, mit dem du sehr viel über das Thema lernen kannst

Jockelx

@EL-europ sagte in Klassenfrage :

ja ich hab den g++ 12.2.0, der kennt auch kein #include <format>

std::format ist da noch nicht drin. Alternativ zu einem Kompiler-update könntest du fmtlib nehmen.
Diese Lib kannst du dann bei Zeiten mehr oder weniger 1:1 gegen std::format austauschen (hoffe ich zumindest - so ist es bei uns geplant).

EL europ

@Schlangenmensch
Betreff:
_Display *Display
_Apple * Apple
... meint
Ich soll im Konstruktor der _Userinterface ein eigenes Objekt "_Display" mit new instazieren? Das hab ich eben schnell versucht und zum Beginn der Laufzeit speicherzugriffsfehler erhalten. Oder meinst du eine andere Herangehensweise?

EL europ

@Jockelx
Der zweite zweck der Software ist mit dem Standart der Linuxdistro auszukommen, alle (auch ich) verschieben nur Registerinhalte und machen nix Neues nur anders. Ich will nicht von Fremdbibliotheken abhängen; Natürlich kann ich ohne Andere auch Nichts, aber es soll nicht an Softwarebibliotheken hängen.

Schlangenmensch

@EL-europ Ich bin mir nicht sicher, was du meinst. Ich bin mir nur sicher, dass ich kein new gemeint habe.
Wenn ein Userinterface ein Display haben soll, warum soll das denn auf dem Heap Alloziert werden und ein Pointer in Display sein?

EL europ

@Schlangenmensch
Achso*
Du meinst es brauchen gar keine Objekte instanziert werden wenn ich sowieso nur auf einem "operiere"?

Ich probier mal ohne "new" auszukommen, vermute aber das ich damit alles, auch die Aufrufe, ändern muss

Finnegan

@EL-europ sagte in Klassenfrage :

Du meinst es brauchen gar keine Objekte instanziert werden wenn ich sowieso nur auf einem "operiere"?

Ich denke @Schlangenmensch meint vermutlich so etwas hier:

int main()
{
    _Display Display;
    _Userinterface Ui{ BORDER, BORDER, Display, ui_callback };
    ...
}

das bedeutet nicht, dass keine Objekte instanziert werden, sondern dass sie als automatische Variablen hierbei direkt auf dem Stack liegen und nicht im Heap.

Das bietet sich gerade bei denen besonders an, weil die Objekte zu Beginn des Programms einmal erzeugt werden und über die gesamte Laufzeit erhalten bleiben. Diese Objekte werden dann mit der schließenden geschweiften Klammer am Ende von main automatisch zerstört und deren Destruktoren aufgerufen. Kein delete notwendig.

Der zweite zweck der Software ist mit dem Standart der Linuxdistro auszukommen, alle (auch ich) verschieben nur Registerinhalte und machen nix Neues nur anders. Ich will nicht von Fremdbibliotheken abhängen; Natürlich kann ich ohne Andere auch Nichts, aber es soll nicht an Softwarebibliotheken hängen.

libfmt hat scheinbar auch einen "header-only"-Modus:

Optional header-only configuration enabled with the FMT_HEADER_ONLY macro

Damit wäre das Einbinden sehr simpel, da nur das #include benötigt wird, ohne die Bibliothek extra bauen und linken zu müssen. Du könntest deren Quellcode z.b. in ein Unterverzeichnis deines Projekts kopieren, und die Header von dort einbinden. Ausserdem wäre das nur eine Übergangslösung, bis die Default-Compiler der Distributionen das unterstützen (wenn alles gut geht müsste man dann nur das #include <fmt/format.h> in ein #include <format> und den Namespace bei den Aufrufen von fmt:: nach std:: abändern).

Th69

Doch, es müssen selbstverständlich diese Objekte instanziiert werden, nur eben direkt und nicht als Zeiger:

Display display(...);
Apple apple(...);

Aber du hast noch so viele Design- und Codefehler, daß es wirklich besser wäre, dieses Projekt noch mal neu aufzusetzen.
Hier eine (kurze) Liste der Verbesserungen:

Projektaufbau nach dem 3-Schichten-Modell: UI, Logik und Datenzugriff (Kurzer Überblick, wenn auch mit Java-Code: Wie funktioniert die 3-Schichten-Architektur?), d.h. die Klassen so organisieren, daß sie zu genau einer der Schichten gehören.
Vermeidung von direktem Zugriff auf tiefere Objekte (Daten), wie z.B. Apple->ui->display->xres, d.h. Beachtung des Gesetz von Demeter. Kennen sollte man auch die anderen Prinzipien des Artikels (zumindestens von SOLID sollte man schon gehört haben und diese bei OOP auch beachten).
Nur die Header je Datei einbinden, die auch direkt benötigt werden - und nicht, wie in "_Display.h", alle Systemheader einbinden! In Headerdateien reichen auch meistens Vorwärtsdeklarationen.

Insgesamt ist dein Code auch viel zu lang (für die eigentliche Funktionalität), d.h. es erscheint mir eher eine Copy&Paste-Programmierung zu sein, anstatt Aufteilung in passende (kleinere) Funktionen.

Und dann kommt hinzu, daß eine Umsetzung von C nach C++ nicht bloß das Austauschen von Funktionen bzw. Typen ist (dies wird oft als "C mit Klassen" bzw. "C mit cout" bezeichnet), sondern bei (modernem) C++ werden auch andere Techniken eingesetzt, z.B.

RAII
Smart-Pointer (der deutsche Artikel Intelligenter Zeiger ist nur sehr kurz).
Template
...

EL europ

@Schlangenmensch @Finnegan @Th69
Ich hab es ohne "new" compiliert bekommen, aber es läuft sofort in einen Speicherfehler.

EL europ

@Th69
Copy and Paste ist mein Mittel der Tippfehlervermeidung!
Und Die Paradigmen Anderer zur Umsetzung eigener Programme ist sinnvoll wenn man die Paradigmen schon kennt, man sucht doch aber nicht nach solchen sondern wird kreativ.
Sicher sind Funktionen des Programms optimierbar, aber das sind (mir) im moment "Kinkerlitzchen"

Finnegan

@EL-europ sagte in Klassenfrage :

@Schlangenmensch @Finnegan @Th69
Ich hab es ohne "new" compiliert bekommen, aber es läuft sofort in einen Speicherfehler.

Die Ursache dafür wirst du schon selbst mit den genannten Werkzeugen herausfinden und beheben müssen, da dein Programm nicht nur ein Fraktal generieren möchte, sondern obendrein scheinbar auch noch fraktale Fehler erzeugt ( ), die es sehr schwer machen für jemanden, der nicht genau dasselbe Setup fährt, diesen Fehler nachzuvollziehen (siehe unten, mein Test unter WSL2). Eine IDE mit einem integrierten Debugger ist da übrigens ganz hilfreich - Puristen können gdb auch über die Kommandozeile verwenden (davon weiss ich aber nicht allzu viel).

Wenn du das tatsächlich mit deinem aktuellen Code weiter durchziehen willst, solltest du Sanitizer und Warnungen aktivieren (inklusive -Werror), die auftretenden Fehler einen nach dem anderen ausfindig machen, herausfinden weshalb sie auftreten und die Ursache beseitigen - und dabei natürlich überlegen ob und wie man es vielleicht besser machen könnte. Anders sehe ich nicht, wie du mit dem Programm auf einen grünen Zweig kommen kannst.

Einen Speicherfehler bekomme ich beim Testen übrigens auch, aber sehr wahrscheinlich aus völlig anderen Gründen wie bei dir. Bei mir unter Windows mit WSL2 existiert z.B. das Framebuffer-Device (/dev/fb0) nicht, daher gibt open("/dev/fb0", O_RDWR) in Display.cpp bei mir -1 zurück und strerror(errno) den String No such file or directory.

Leider pfüfst du danach nur, ob fbfile ungleich 0 ist, was du als "kein Fehler" interpretierst (siehe Doku zu open, meiner Ansicht nach ist nicht nur alles was kleiner als 0 ebenfalls ein Fehler, sondern auch noch 0 ein gültiger File-Deskriptor, also kein Fehler) und dein Code macht munter weiter als wäre nichts gewesen

Auch mit Fehlerbehandlungen wie in solchen Zeilen:

if (ioctl(fbfile, FBIOGET_FSCREENINFO, &Finfo)){return;}
if (ioctl(fbfile, FBIOGET_VSCREENINFO, &Vinfo)){return;}

Damit machst du dir und anderen nur das Leben schwer, da hat man praktisch keine Chance als Nutzer der Display-Klasse herauszufinden, ob die Initialisierung nun erfolgreich war oder nicht - geschweige denn warum sie überhaupt fehlgeschlagen ist.

Eine Möglichkeit, solche Fehler sauber zu handhaben wären Exceptions. Das könnte dann z.B. so oder ähnlich aussehen:

_Display.cpp

...
#include <string>
#include <cstring>
#include <stdexcept>
...

Display::Display()
{
    ...
    
    fbfile = open("/dev/fb0", O_RDWR);
    if (fbfile < 0)
        throw std::runtime_error{
            std::string{ "Unable to open '/dev/fb0': " } + std::strerror(errno)
        };

    ...

    if (
        ioctl(fbfile, FBIOGET_FSCREENINFO, &Finfo) < 0
        || ioctl(fbfile, FBIOGET_VSCREENINFO, &Vinfo) < 0
    )
        throw std::runtime_error{
            std::string{ "Failed to acquire framebuffer screen information for '/dev/fb0': " }
            + std::strerror(errno)
        };

...

mandel.cpp:

...
#include <iostream>
#include <stdexcept>
...
int main()
{
    try
    {
        ...
        //Programmende
        return 0;
    }
    catch (const std::exception& e)
    {
        std::cerr << "ERROR: " << e.what() << std::endl;
        return 1;
    }
    catch (...)
    {
        std::cerr << "Unexpected exception!" << std::endl;
        return 2;        
    }
}

Edit: Exceptions sind natürlich noch ein Grund mehr auf manuelle Speicherverwaltung zu verzichten. Stichwort Exception Saftety. Bezogen auf die Display-Klasse könnte man fbspiegel wahrscheinlich als std::vector<uint8_t> umsetzen und das Memory Mapping (mmap/munmap) über einen std::unique_ptr<uint8_t> mit Custom Deleter erschlagen.

Z.B. so oder ähnlich (ungetestet):

#include <memory>

class Display
{
    ...
    std::unique_ptr<std::uint8_t> fbpointer;
    ...
};

Display::Display()
{
    ...
    fbpointer = std::unique_ptr{
        static_cast<std::uint8_t*>(
            mmap(
                0, 
                bufferlength, 
                PROT_READ | PROT_WRITE, 
                MAP_SHARED, 
                fbfile,
                0
            )
        ),
        [&](std::uint8_t* ptr){
        {
            munmap(ptr, bufferlength);
        }
    };
    ...
}

Der std::unique_ptr ruft nämlich automatisch den Deleter (hier die Lambda-Funktion) auf, wenn er zerstört wird. Auch dann, wenn Display nicht vollständig konstruiert wurde.

Das Problem, wenn im Konstruktor eine Exception fliegt ist nämlich, dass zwar für alle bereits konstruierten Member-Variablen die Destruktoren aufgerufen werden, nicht aber für Display selbst. Das macht es schwierig, mit manuellem malloc/free oder map/unmap den Konstrukor exception-sicher hinzubekommen, so dass die bis dahin reservierten Ressourcen auch alle wieder freigegeben werden.

Die Lösung ist hier RAII zu verwenden, z.B. mit dem genannten std::vector und dem std::unique_ptr. Dann klappts auch, wenn die Ausnahmen fliegen