Nun haben Sie das Buch gelesen und überlegen sich, wie Sie jetzt wohl weitermachen können. Ein paar Tipps dazu kann ich Ihnen auf den folgenden Seiten geben.

28 Wie geht’s jetzt weiter?

Wenn Sie das Buch ganz gelesen und durchgearbeitet haben, können Sie sich jetzt als fortgeschrittenen Programmierer in C bezeichnen. Der Weg zum Guru ist also nicht mehr weit.

Mit der Sprache C haben Sie sich die allgemeinen Grundlagen der Programmierung angeeignet, doch was kommt jetzt? Mit C allein wird wohl kaum jemand noch seinen Lebensunterhalt verdienen. Gewöhnlich gehen Programmierer im Anschluss folgende Wege:

• Sie steigen in die Systemprogrammierung von Linux oder Windows ein (besonders Wissensdurstige können natürlich auch gleich mit beiden Systemen anfangen). Dabei wird vorausgesetzt, dass Sie die Sprache C beherrschen (dies dürfte nach der Lektüre dieses Buches kein Problem mehr sein) und dass Sie sich mit dem entsprechenden Betriebssystem auskennen. Sofern Sie ein Linux-Fetischist sind, kann ich Ihnen mein aktuelles Buch »Linux-UNIX-Programmierung« empfehlen.

• Sie lernen C++. Um mit der Programmiersprache C++ anzufangen, kann es (entgegen einiger anderer Meinungen) von Vorteil sein, dass Sie die Sprache C bereits beherrschen. Es ist aber nicht unbedingt notwendig. C++ kann auch unabhängig von C erlernt werden. Als Einstieg könnte ich Ihnen mein Buch »C++ von A bis Z« empfehlen, das ebenfalls beim Rheinwerk Verlag erschienen ist.

28.1 GUI-Programmierung – grafische Oberflächen

Da Ihnen nach diesem Buch nun Tür und Tor offen stehen, werden sich einige Programmierer auch gern einmal an die »grafische« Programmierung heranwagen wollen, was ohne Weiteres zu empfehlen ist. Allerdings ist aller Anfang auch hier schwer. »Schwer« ist hierbei nicht die Verwendung einer entsprechenden Bibliothek, sondern eher den Überblick zu wahren bzw. den Einstieg zu finden. Bevor Sie sich an die »grafische« Programmierung heranwagen, sollten Sie erst mal überdenken, welche Art von »grafischer« Programmierung Sie einsetzen wollen. Generell unterscheide ich hierbei drei verschiedene Arten der »grafischen« Programmierung.

28.1.1 Low-Level-Grafikprogrammierung

Damit bezeichne ich die tiefste Ebene der »grafischen« Programmierung. Hierbei müssen Sie sich um alle Details selbst kümmern. Sie wollen praktisch jeden Punkt, jede Linie und jedes kleine Detail (genauer die Grafik-Primitiven) selbst zeichnen.

Gewöhnlich greifen Sie dabei auf die systemnächste Grafikschnittstelle des Betriebssystems zu. Unter MS-Windows wäre dies die Win32-API, und unter Linux/UNIX ist es die Xlib (auch als X11 bekannt). Fast alle höheren Grafik-Bibliotheken bauen auf dieser Ebene auf. Häufig wird hierbei als Programmiersprache C verwendet.

Sehr gut geeignet ist diese systemnahe Grafikschnittstelle zum Entwickeln einer eigenen Spiele-Bibliothek oder eines Windowmanagers, mit dem Sie Ihrer Oberfläche ein eigenes Look & Feel verpassen können (beispielsweise KDE oder GNOME unter Linux).

Der Nachteil, wenn Sie diese niedrige Ebene verwenden, ist eine sehr lange Einarbeitungszeit sowie langer und komplizierter Quellcode. Außerdem sind gute Mathematikkenntnisse erforderlich, und die Programmierung ist systemabhängig. Die Low-Level-Grafikprogrammierung ist also für Anfänger nur bedingt geeignet.

Natürlich haben Sie hiermit den Vorteil, dass Sie eine eigene schlanke Bibliothek entwickeln können, die Ihren Vorstellungen entspricht. Des Weiteren lernen Sie dabei, wie grafische Oberflächen aufgebaut sind, was Ihnen auf jeden Fall zu einem besseren Verständnis beim Verwenden einer anderen grafischen Bibliothek verhilft. Dabei werden Sie feststellen, dass das Prinzip einer grafischen Bibliothek immer dasselbe bleibt.

28.1.2 High-Level-Grafikprogrammierung

Alle Grafikbibliotheken der höheren Ebene basieren meistens auf der niedrigeren Ebene (Win32 bzw. X11). Bei solchen Bibliotheken können Sie vieles mit lediglich einem Funktionsaufruf erledigen. Alle unangenehmen Arbeiten werden Ihnen abgenommen. Häufig wird dabei auch Systemabhängiges versteckt bzw. eine Cross-Plattform-Bibliothek dafür angeboten. Damit lassen sich viele Bibliotheken der höheren Ebene auch auf mehreren Systemen verwenden.

Vorwiegend werden solche Bibliotheken verwendet, um die auf dem System basierenden typischen Look&Feel-Anwendungen wie »Outlook« bzw. »Kmail« zu entwickeln – also typische fensterbasierende Anwendungen. Hierbei ist die Programmiersprache nicht mehr von primärer Bedeutung, da es häufig Schnittstellen für mehrere Sprachen gibt (für C bzw. C++ gibt es generell immer eine Schnittstelle). Meistens wird einer solchen Bibliothek auch eine Dokumentation mitgegeben, womit die Einarbeitung wesentlich leichter fällt.

Bekannte Beispiele für eine solche Bibliothek wären unter MS-Windows MFC (Microsoft Foundation Classes), eine objektorientierte Version der Win32-API, und OWL, die Borland-Alternative zu MFC. Unter MS-Windows gibt es eine Menge freier Bibliotheken zur High-Level-Grafikprogrammierung (beispielsweise GTK+, Qt usw.). Unter Linux werden vorwiegend die Bibliotheken GTK+ und die GNOME-Lib (für GNOME) oder Qt für den KDE-Desktop verwendet. Allerdings gibt es auch hier eine Menge Alternativen.

Der Nachteil von solchen höheren Bibliotheken ist, dass die Anwendungen manchmal etwas »fett« werden und eine Menge unnötigen Ballast mit sich herumtragen.

Allerdings überwiegt der Vorteil, dass das Erstellen einer Anwendung wesentlich schneller und komfortabler von der Hand geht (ein wenig Einarbeitungszeit vorausgesetzt). Voraussetzung ist allerdings immer, dass sich der Programmierer mit seinem Werkzeug (besonders mit dem Compiler und Linker) auskennt. Dies ist beispielsweise nicht gegeben, wenn er schon daran scheitert, eine einfachste (Hallo-Welt-)Anwendung mit dieser Bibliothek zu übersetzen.

RAD-Tools

Noch einfacher wird es dem Programmierer mit sogenannten RAD-Tools (Rapid Application Development) oder auch GUI-Designern gemacht. Hierbei ist es fast möglich, ohne Programmierkenntnisse eine grafische Anwendung zusammenzuklicken. Die GTK+-Bibliothek bietet beispielsweise mit GLADE ein solches Tool an. In den meisten C#-Compilern ist ebenfalls ein solches Tool vorhanden. Zwar werden die RAD-Tools immer besser und nehmen dem Programmierer eine Menge Arbeit ab, aber wenn es um Details geht, sind weiterhin Programmierkenntnisse notwendig. Ein Mix aus beidem (RAD-Tool und dem Programmieren »von Hand«) führt wohl zum besten Ergebnis.

28.1.3 Multimedia-Grafikprogrammierung

Ebenfalls basierend auf der niedrigen Ebene sind sogenannte Multimedia-Bibliotheken aufgebaut. Multimedia-Bibliotheken werden vorwiegend zur Programmierung von Spielen, Demos aber auch in der Filmindustrie zum Einfügen von Spezialeffekten verwendet. Bei diesen Bibliotheken werden dem Programmierer eine Menge Arbeiten abgenommen – und vieles lässt sich mit einem Funktionsaufruf realisieren. Auch bei diesen Bibliotheken gibt es einige »systemunabhängige« Vertreter wie beispielsweise OpenGL, Allegro oder SDL, die auf vielen Plattformen vorhanden sind.

Die Programmiersprache ist nicht unbedingt von Bedeutung, da es häufig die eine oder andere Schnittstelle zu anderen Sprachen gibt, aber in der Praxis werden die meisten Spiele, Demos bzw. Multimedia-Anwendungen in C/C++ erstellt. Viele dieser Bibliotheken sind sehr gut dokumentiert, und es sind häufig auch eine Menge Quellcodes und Demos zum Studieren vorhanden. Zu DirectX (dem »Platzhirsch«, mit dem sehr viele (aber nicht nur) Spiele programmiert werden) gibt es mittlerweile eine Menge deutschsprachiger Literatur, weshalb hier der Einstieg besonders leicht fällt. Allerdings ist DirectX eine Microsoft-eigene Bibliothek und eben nur unter diesem System ausführbar.

Voraussetzungen für die Multimedia-Programmierung sind sehr gute Mathematikkenntnisse (lineare Algebra), räumliches Denken (sofern Sie sich für die 3D-Programmierung interessieren) und sehr viel Zeit;-).

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.