Kapitel 29 Wie geht’s jetzt weiter?

Jetzt haben Sie das Buch gelesen und überlegen sich, wie Sie jetzt wohl weitermachen können. Ein paar Tipps dazu kann ich Ihnen auf dieser Seite geben.

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

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

Sie steigen ein in die Systemprogrammierung von Linux oder Windows (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 dem Buch kein Problem mehr sein) und dass Sie sich mit dem entsprechenden Betriebssystem auch 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 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.

29.1 GUI-Programmierung – Grafische Oberflächen 

Da Ihnen nach diesem Buch nun Tür und Tor offen stehen, werden sich einige Programmierer auch gerne mal 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.

29.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 systemnaheste 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 einem Windowsmanager, womit Sie Ihrer Oberfläche ein eigenes Look & Feel verpassen können (bspw. KDE oder GNOME unter Linux).

Der Nachteil, wenn Sie diese niedrige Ebene verwenden, ist, eine sehr lange Einarbeitungszeit, langer und komplizierter Quellcode, gute Mathematikkenntnisse sind erforderlich und sie ist systemabhängig. 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 zum besseren Verständnis beim Verwenden einer anderen grafischen Bibliothek hilft. Dabei werden Sie feststellen, dass das Prinzip einer grafischen Bibliothek immer dasselbe bleibt.

29.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.

Platzhirsche einer solchen Bibliothek wären unter MS-Windows MFC (Microsoft Foundation Classes) eine objektorientierte Version der Win32-API und OWL, die Borland-Alternative zu MFC. Wobei es unter MS-Windows eine Menge freier Bibliotheken hierzu gibt (bspw. 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 die Erstellungszeit einer Anwendung wesentlich schneller und komfortabler von der Hand geht (ein wenig Einarbeitungszeit vorausgesetzt). Vorraussetzung ist allerdings immer, dass sich der Programmierer mit seinem Werkzeug (besonders dem Compiler und Linker) auskennt. Dies ist bspw. nicht gegeben, wenn dieser schon daran scheitert, eine einfachste (Hallo-Welt) Anwendung mit dieser Bibliothek zu übersetzen.

RAD-Tools

Noch einfacher wird es dem Programmierer mit so genannten RAD-Tools (RAD = Rapid Application Development) oder auch GUI-Designer gemacht. Hierbei ist es fast möglich, ohne Programmierkenntnisse eine grafische Anwendung zusammen zu klicken. Die GTK+-Bibliothek bietet bspw. mit GLADE ein solches Tool an. Ebenfalls in den meisten C#-Compilern ist 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 »von Hand« programmieren) führt wohl zum besten Ergebnis.

29.1.3 Mutimedia-Grafikprogrammierung 

Ebenfalls basierend auf der niedrigen Ebene sind so genannte Multimedia-Bibliotheken aufgebaut. Multimedia-Bibliotheken werden vorwiegend zur Programmierung von Spielen, Demos aber auch in der Filmindustrie zum Einfügen von Spezial-Effekten 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 bspw. OpenGL, Allegro oder SDL, welche 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. Multimediaanwendungen 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, womit sehr viele (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.

Vorraussetzung 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 zur Verfügung ;-).