Archive for the 'C\C++' Category

Ich staunte nicht schlecht darüber, als ich teils von Hand, teils vom QtCreator erzeugte GUI-Klassen nicht in Netbeans compilieren ließen.
Im Grunde bin ich mal wieder dabei ein sinnvolles und nutzbares Programm für den Hausgebrauch zu schreiben. Und das sollte nach Möglichkeit auch eine GUI haben. Obendrein war die Arbeit mit Qt auch mal angedacht gewesen.

Nun aber zu meinem eigentlichen Problem. Wenn ich zum Beispiel folgende Quelltexte versuchte zu compilieren, bekam ich stets diesen Fehler in Netbeans:

In function `TonerMainWindow':
/home/compiler/Netbeans-workspace/TonerV/TonerMainWindow.cpp:28: undefined reference to `vtable for TonerMainWindow'

Da wollte er weder den Konstruktor noch den Destruktor annehmen.

Der Code dazu:
tonermainwindow.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

#ifndef _TONERMAINWINDOW_H
#define	_TONERMAINWINDOW_H
 
#include // ein Haufen Qt-Includes
 
class TonerMainWindow : public QMainWindow {
   Q_OBJECT 
public:
    QAction *actionBestand_anzeigen;
    QAction *actionToner_aus_geben;
    QAction *action_Beenden;
    QAction *action_ber_das_Programm;
    QWidget *centralwidget;
    QTableWidget *tableWidget;
    QPushButton *neuerTonerBtn;
    QPushButton *mengeAddBtn;
    QMenuBar *menubar;
    QMenu *menuAktionen;
    QMenu *menuInfo;
    QStatusBar *statusbar;
 
    TonerMainWindow();
    virtual ~TonerMainWindow(){ };
    void setupGUI(QMainWindow *TVMainWindow);
    void retranslateGUI(QMainWindow *TVMainWindow);
 
protected:
    //void changeEvent(QEvent *e);
 
private:
 
private slots:
 
};
 
#endif	/* _TONERMAINWINDOW_H */

tonermainwindow.cpp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#include "TonerMainWindow.h"
 
TonerMainWindow::TonerMainWindow()
{
    setupGUI(this);
}
 
void TonerMainWindow::setupGUI(QMainWindow *TVMainWindow)
    {
        ... ganz viel Code ...
    } 
 
    void TonerMainWindow::retranslateGUI(QMainWindow *TVMainWindow)
    {
        ... ganz viel Code ...
    }

Ich habe anschließend gegoogelt, weil ich mit vtable so gar nichts anfangen konnte. Irgendwo habe ich dann auch gelesen, dass der vtable-Fehler eigentlich immer dann auftritt, wenn eine mit dem Schlüsselwort virtual markierte Funktion nicht definiert ist. Die einzige virtuelle Funktion wäre hier der Destruktor, der aber aus Gründen der Mehrfachvererbung in C++ immer als virtuelle Funktion definiert werden sollte.
Ahnungslos, was da eigentlich der Grund für diesen Fehler sein könnte, habe ich dann eine private Try-and-Error-Session eingelegt. Ich habe es mit Weglassen und später auch mit dem Makefile probiert. (Die Makefile-Episode lässt sich übrigens gleich hier nachlesen.)
Eine Googlesuche gab auch nicht viel her. Irgendwann hatte ich dann mal den Code so verändert, dass TonerMainWindow keine abgeleitete Klasse von QMainWindow ist, sondern eine Membervariable vom Typ QMainWindow besaß. Anschließend habe ich den Aufruf von setupGUI im Konstruktor so verändert, das da nicht mehr this sondern der Name der Membervariable da stand. Nach erfolgreichem Übersetzungsvorgang und Start des Programms, bekam ich endlich ein Fenster zu sehen.

Aber das war nicht die endgültige Lösung. Irgendwie konnte ich mich nicht ganz mit dem Gedanken abfinden, keine abgeleiteten Klassen zu verwenden. In Java mache ich das schließlich bei Swing-GUIs genauso. Aus Neugier habe ich dann Q_Object auskommentiert und es lief!
Q_Object ist ein Makro, aber was das treibt und für was das eigentlich gut sein soll, weiß ich nicht. Aber Hauptsache, es läuft.

Nachdem ich so eine Weile auf der ReactOS Mailing Liste mitgelesen und schnell gemerkt habe, dass ich von der Betriebsystementwicklung so gut wie keine Ahnung habe, wende ich mich doch lieber etwas “einfacheren” Themengebieten zu. Bei gewissen Begrifflichkeiten, wie sie auf der Mailingliste diskutiert werden, hört es für mich einfach auf. Hier ein Beispiel:

I notice that in Windows Vista – and also Windows XP – there seems to be an undocumented field in PEB.

Was, bitte schön, soll PEB sein? Also lassen wir das mal.

Ich wollte mich sowieso mal mit etwas Grafischen beschäftigen. Mit der Bibliothek Allegro habe ich bisher ein wenig herumgespielt und zwischendurch auch mal OpenGL angetestet. Für den etwas vorbelasteten Leser in diesem Bereich, sei gesagt:

Nein, es wird nicht der nächste mega Spieletitel mit der bestechenden High-End Grafik.

(Bitte nicht in Tränen ausbrechen ) Erst einmal klein anfangen. Im Grunde habe ich vor, mit Blender erzeugte Quake 2 Modelle zu laden und anschließend zu rendern. Für das Darstellen des 3D Objektes, habe ich von Anfang an eine Verbindung aus Allegro und OpenGL vorgesehen. Nur in Sachen Format war ich mir vor kurzem noch nicht sicher. Das Format sollte aber auf alle Fälle nicht allzu kompliziert sein. Daher habe ich zunächst einiges an Exportformaten von Blender angeschaut. Von den rohen Koordinaten der einzelnen Punkte (Vertices) bishin zu XML-artigen Modelbeschreibungen war alles vertreten. Einen langsamen und fehlerträchtigen XML-Parser wollte ich mir (und dem Programm) dann doch nicht zumuten.

Die Quake-Dateiformate waren mir als sehr populär in bekannt, da einige freie Spieleengines sowie freie Spiele wie z.B. Sauerbraten davon Gebrauch machen. Vorallem lässt sich das Format auch gut in C handhaben, da sich am Anfang der Datei ein Abschnitt befindet, der zum Beispiel Informationen beinhaltet, aus wievielen Dreiecken sich ein 3D Objekt zusammensetzt. So muss man nicht ständig neuen Speicher anfordern, sondern kann die nötige Menge vorab anfragen. Um das Dateiformat zu verstehen, benutze ich die bekannte Spezifikation von Daniel E. Schoenblum.

Jetzt muss ich mir nur noch einen Weg erarbeiten, wie ich die Daten aus der Datei sinnvoll mit Allegro verwenden kann.