welche programmiersprache für Programme benutzen?

Dravere schrieb:

C++ ist keine Erweiterung von C, sondern eine eigenständige Sprache. Wenn es eine Erweiterung wäre, müsste es ja zum Beispiel rückwärtskompatibel zu C99 sein, ist es aber nicht!

Eine ganz schlechte Begründung.
C++ war bei seiner Geburt ein Spin-Off von C. Daß C inzwischen eigene Wege ging und C++ hinter sich lies (durch C99), heißt nicht, daß man C++ nicht auch als Erweiterung von C ansehen kann. Stroustrup selbst sagte einst während eines Interviews: "C++ is a better C".

wxSkip

veritySeeker schrieb:

Daß C inzwischen eigene Wege ging und C++ hinter sich ließ (durch C99)...

Und jetzt versucht C++0x, wieder C99-Konform zu werden.

knivil

Stroustrup selbst sagte einst während eines Interviews: "C++ is a better C".

Ja und? Ueber Java sagt man, es sei ein besseres C++. Dennoch ist Java keine Erweiterung von C++. Alles Bullshit.

Bestes Beispiel das C++ keine Erweiterung von C ist:

int *a = malloc(sizeof(int));

In C legal, in C++ nicht.

nwp2

wxSkip schrieb:

Zu C++: Klassen und Vererbung sind zwar das, was man an C++ vielleicht am meisten spürt, aber Prozentual ist das halt trotzdem nicht so viel. Außerdem bringen diese kleinen "Erweiterungen" sehr viel für das Programmieren von Bibliotheken, vergleiche halt mal WinAPI mit einem modernen GUI-Toolkit (auch wenn so was wie wxWidgets auch nicht modernstens programmiert ist).

Da muss ich massiv widersprechen. Ich bastle an einem größeren Projekt mit der WinAPI, es klappt ziemlich gut. Manchmal muss ich etwas suchen, aber am Ende habe ich immer die entsprechende Funktion gefunden.

Dann wollte ich es nach Linux portieren. Alles ist gut modularisiert, man muss nur eine handvoll Funktionen finden die ein Fenster aufmachen und Text malen. Ich habe es mit QT versucht und habe es aufgegeben, wegen C++. Man findet nichts. Mein Versuch mit GTK ist daran gescheitert, dass es keine Dokumentation gibt, nur für die C++ Bindings. Ich suche gezielt nach C-Bibliotheken weil die so einfach zu benutzen sind und meide C++ Bibliotheken weil man da überhaupt nicht durchsehen kann.

nwp2 schrieb:

Ich habe es mit QT versucht und habe es aufgegeben, wegen C++.

Wenn du Qt nicht benutzen kannst, dann solltest du das Programmieren vielleicht ganz sein lassen. Qt ist mit Abstand die am einfachsten zu benutzende Bibliothek mit der besten Dokumentation.

Tausend mal besser als die ganzen C Bibliotheken mit kryptischen Namen, Void-Zeigern und endlos vielen unnötigen Strukturen.

knivil

Qt und WinAPI sind zwei verschieden Konzepte (insbesondere der signal-slot-Mechanismus), die sich auch auf das Programmdesign auswirken. Eine reine Portierung ist damit ausgeschlossen.

nwp2

Warum mir alle immer die Programmiererei ausreden wollen, ich muss wirklich schrecklich sein. Aber im ernst, ich habe meine GUI-Funktionen komplett von der Programmlogik abgekapselt. Es gibt nur Funktionen wie "mache ein Fenster auf", "male Text an diese Stelle" und so weiter. Ganz primitive Funktionen die jede GUI-Bibliothek hat. Und bei QT findet ich sie einfach nicht, denn ich komme mit den ganzen Window, Widget, Cairo, Device und wie-sie-alle-hießen Klassen nicht klar. Es gibt auch keine Dokumentation, es gibt nur Doxygen-generierte Header im HTML-Format. Außerdem gibt es bestimmt 5 verschiedene Klassen für Schriftarten und Devicecontexte die alle miteinander inkompatibel sind. Das beste was man machen kann ist sich von Tutorial zu Tutorial zu hangeln, aber wirklich vorwärts gekommen bin ich so nicht.
Ich hatte übrigens daran gedacht direkt XServer-Funktionen zu nehmen. Damit kann man nämlich ganz einfach Fenster aufmachen und Text malen. Allerdings müsste ich auch Menüs selber bauen, und darauf hatte ich keine Lust.

Wenn ich irgendwann soweit bin dass es sich wirklich lohnt nach Linux zu porten werde ich mich damit nochmal beschäftigen.

Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.

knivil

nwp2 schrieb:

Warum mir alle immer die Programmiererei ausreden wollen, ich muss wirklich schrecklich sein. Aber im ernst, ich habe meine GUI-Funktionen komplett von der Programmlogik abgekapselt. Es gibt nur Funktionen wie "mache ein Fenster auf", "male Text an diese Stelle" und so weiter. Ganz primitive Funktionen die jede GUI-Bibliothek hat. Und bei QT findet ich sie einfach nicht, denn ich komme mit den ganzen Window, Widget, Cairo, Device und wie-sie-alle-hießen Klassen nicht klar.

Warum sagen alle anderen, Qt sei Klasse?

Es gibt auch keine Dokumentation, es gibt nur Doxygen-generierte Header im HTML-Format.

Mega Bullshit: http://doc.trolltech.com/4.6/index.html . Da gibt es Tutorials, massenhaft Hintergrundwissen, alles was das Herz begehrt.

aber wirklich vorwärts gekommen bin ich so nicht

Dann hast du was falsch gemacht.

"male Text an diese Stelle"

GUIs abstrahieren vom Rendering. Falls du Rendering willst anstatt 'ne GUI, dann solltest du keine GUI nehmen. Es gibt jedoch Moeglichkeiten: z.B. Label erzeugen, Text setzen, Label auf Position setzen.

Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.

Du hast nichts gelernt.

ipsec

nwp2 schrieb:

ich habe meine GUI-Funktionen komplett von der Programmlogik abgekapselt. Es gibt nur Funktionen wie "mache ein Fenster auf", "male Text an diese Stelle" und so weiter. Ganz primitive Funktionen die jede GUI-Bibliothek hat.

Ich zweifle ernstlich, ob du dich schonmal mit GUI-Programmierung intensiv auseinander gesetzt hast. Man malt sich seine Oberfläche doch nicht selber, dafür gibt es z.B. unter Windows die STATIC-Fensterklasse oder irgendeine andere angepasstere. Was machst du, wenn du einen Button haben willst? Malst du da ein weißes Rechteck mit schwarzem Rand?

nwp2 schrieb:

Es gibt auch keine Dokumentation, es gibt nur Doxygen-generierte Header im HTML-Format.

Bitte was? Qt ist m.E. eine der bestdokumentierten C++-Bibliotheken überhaupt. Zur Dokumentation von Qt 4.7 gehts hier.

nwp2 schrieb:

Außerdem gibt es bestimmt 5 verschiedene Klassen für Schriftarten und Devicecontexte die alle miteinander inkompatibel sind.

Oha. Für Schriftarten kenne ich QFont, für Device-Kontexte... äh, wozu brauch man Device-Kontexte? Durch die Abstraktion muss man sich doch mit sowas dankenswerterweise nicht mehr rumschlagen.

nwp2 schrieb:

Das beste was man machen kann ist sich von Tutorial zu Tutorial zu hangeln, aber wirklich vorwärts gekommen bin ich so nicht.

Die Tuts sollte man sich bei jeder Bibliothek mal anschauen, aber gerade bei Qt sind die m.E. sehr verständlich.

nwp2 schrieb:

Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.

Das ist natürlich immer eine Sache des Geschmacks, aber für mich ist WinAPI viel zu low-level und zu unportabel.

nwp2 ist ein guter Entwickler.

nwp2 weiß wie man Qt benutzt.

nwp2 ist ein Noob.

nwp2

Ich nehme das über die Doku von QT zurück. Hab QT mit GTK verwechselt. QT hatte ich aufgegeben wegen c++. Das war wohl etwas vorschnell.

"male Text an diese Stelle"

GUIs abstrahieren vom Rendering. Falls du Rendering willst anstatt 'ne GUI, dann solltest du keine GUI nehmen. Es gibt jedoch Moeglichkeiten: z.B. Label erzeugen, Text setzen, Label auf Position setzen.

Meine Programmlogik erfordert aber nunmal, dass ich ein Fenster mit Menü habe und dort Text reinmalen kann. Meine Idee war, dass ich einfach die Textmalfunktionen ersetze und schon läufts unter Linux.
Dass es die Funktionen, die ich mir überlegt habe, in QT nicht gibt, zeigt mir eigentlich nur, dass QT ungeeignet dafür ist.

Ich habe auch etwas in der QT-Doku geblättert und weiß wieder warum ich QT doof fand. Ich will zum Beispiel eine Linie malen. Ich finde die QGraphicsLineItem Klasse. Dort schickt man mich zu QGraphicsScene. Um die zu erzeugen brauche ich ein QObject. Und nein, ein Fenster ist kein QObject. Also muss ich irgendwie herausfinden, wie ich aus dem Fenster ein QObject mache um eine QGraphicsScene zu erzeugen die ein QGraphicsLineItem hat welches mit eine Linie mal. Wenn es so überhaupt möglich ist.

Da lob ich mir die WinAPI, DrawLine und fertig.

Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.

Du hast nichts gelernt.

Doch, ich habe gelernt, dass ich als Vollnoob super mit der WinAPI arbeiten kann und trotz reichlich mehr Erfahrung aus QT nicht schlau werde.
Ich kann mir gut vorstellen, dass QT super funktioniert, wenn man sein Programm um QT herum baut. Wenn man sich allerdings Funktionen überlegt und die mit QT implementieren will funktionierts nicht. Da ich wegen Portabilität auf letzteres angewiesen bin (Nein, ich will keine 13MB von QT für Windows mitschleppen), bleibt mir nichts weiter übrig, als eine andere Bibliothek zu suchen.

GUIs abstrahieren vom Rendering.

Das erklärt warum es nicht funktioniert wie ich das wollte. Aber es ändert nichts an der Tatsache dass es nicht funktioniert.

knivil

Und nein, ein Fenster ist kein QObject.

Direct aus der Doku:

The QWidget class is the base class of all user interface objects. More...
#include <QWidget>
Inherits QObject and QPaintDevice.

Doch ist es! Und wenn es dir um Linien zeichnen geht, bietet das http://doc.trolltech.com/4.6/widgets-analogclock.html ein gutes Tutorial. Text geht bestimmt auch.

Da lob ich mir die WinAPI, DrawLine und fertig.

Ja, genau das ist es. Und deswegen funktioniert es auch. Falls du mal etwas mehr machen willst, Kannst du gern QGraphicsScene/-view und die entsprechenden Items benutzen. Tetris gibt es uebrigens auch als Tutorial: http://doc.trolltech.com/4.6/widgets-tetrix.html

Du kannst natuerlich das benutzen, was du willst. Aber von Qt abraten, nur weil du zu unfaehig oder unmotiviert bist, dich einzuarbeiten, ist einfach dumm.

nwp2 schrieb:

Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.

Du könntest GTK nehmen, dort hast Du beides, Lowlevel-Funktionen und Abstraktion. Und GTK ist auch portabel, anders als die WinAPI.

knivil schrieb:

Warum sagen alle anderen, Qt sei Klasse?

Sagen das alle anderen?

Und nochwas: GTK hat reine C-Schnittstellen, Du brauchst daher keine seltsamen C++-Tricks zu verwenden.

ipsec

Offenbar ist Qt wirklich nix für dich. Qt ist eine GUI-Bibliothek und keine Bibliothek zum Zeichnen. Ich sage es nochmal: Man zeichnet seine Benutzeroberfläche in der Regel nicht selbst. Warum musst du eine Linie zeichnen können oder Text malen? Wenn es der GUI-Entwurf erfordert, dass an einer bestimmten Stelle ein Text steht, warum nimmst du dann nicht an diese Stelle ein Label? Wozu brauchst du die Linie? gehört sie zu einem Button, einer Listbox, einem Panel, ...? Warum nimmst du dann kein Button, Listbox, Panel? Ich habe noch nie ein Programm gesehen, wo irgendwo eine einfache Linie war. Und wenn du doch eine ausgefallene Komponente hast, gibt es auch in Qt genug Möglichkeiten, dass die Widgets sich selbst zeichnen. In der Doku findest du das unter http://qt.nokia.com/doc/4.7-snapshot/paintsystem.html#classes-for-painting. Was für dich am erfolgversprechendsten ist, ist wohl ein QPainter. Dem kannst du im Konstruktor dein Fenster-Widget übergeben und dann hat der viele schöne Funktionen zum Zeichnen.

knivil

ipsec schrieb:

Qt ist eine GUI-Bibliothek und keine Bibliothek zum Zeichnen.

Qt bietet fuer alles was. Es laesst eigentlich keine Wuensche offen.

ipsec

knivil schrieb:

ipsec schrieb:

Qt ist eine GUI-Bibliothek und keine Bibliothek zum Zeichnen.

Qt bietet fuer alles was. Es laesst eigentlich keine Wuensche offen.

Ok, ich verbessere: Qt ist eine GUI-Bibliothek und nicht fürs Zeichnen gedacht (bietet ein hohes Maß an Abstraktion, dass man i.d.R. nicht zeichnen muss).

nwp2

ipsec schrieb:

Ich zweifle ernstlich, ob du dich schonmal mit GUI-Programmierung intensiv auseinander gesetzt hast. Man malt sich seine Oberfläche doch nicht selber, dafür gibt es z.B. unter Windows die STATIC-Fensterklasse oder irgendeine andere angepasstere. Was machst du, wenn du einen Button haben willst? Malst du da ein weißes Rechteck mit schwarzem Rand?

Ich habe mich soweit mit GUIs beschäftigt, dass ich Menüs, Buttons, Scrollbars und Tabs mit der WinAPI implementiert habe.
Wenn ich einen Button will mache ich mir eine Buttonklasse.

class button{
    void settext(char *text);
    void setPosition();
    void (*callbackFunction)(const char *text);
}

Und danach überlege ich mir wie ich das implementiere. Und dann suche ich bei MSDN nach button und finde "create a button using the BUTTON class with the CreateWindow or CreateWindowEx function".

Bei QT will ich auch nach Button suchen, doch auf http://doc.trolltech.com/4.6/index.html scheint es keine Suche zu geben. Fein, dann halt auf http://qt.nokia.com/doc/4.7-snapshot/index.html. Es gibt eine Suche, aber wenn ich da was eintippe kommt eine JavaScript-Meldung und sagt Start Search. Das klingt so dämlich, davon hab ich einen Screenshot gemacht. Auch wenn ich enter oder Search klicke passiert nichts.
Naja, es gibt ja noch google, und schon findet man QPushButton::QPushButton ( const QString & text, QWidget * parent = 0 ).
Sieht aus als wäre es das was ich will. Parent ist wohl das Fenster wo der Button rein soll. Wie macht man aus einem QMainWindow ein QWidget? Und schon drehe ich mich wieder endlos im Kreis.
Ein Stück weit ist es meine Unerfahrenheit mit QT, aber für einen großen Teil mache ich die Vererbung der endlos vielen Klassen verantwortlich.

... äh, wozu brauch man Device-Kontexte? Durch die Abstraktion muss man sich doch mit sowas dankenswerterweise nicht mehr rumschlagen.

Fein, dann erklär mir wie ich meine Linie malen soll. Devicecontexte braucht keiner, soweit geh ich mit. Aber irgendeine Möglichkeit eine maleLinie(int x1, int y1, int x2, int y2, struct farbe f)-Funktion zu implementieren muss es doch geben.

nwp2 schrieb:

Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.

Das ist natürlich immer eine Sache des Geschmacks, aber für mich ist WinAPI viel zu low-level und zu unportabel.

Low-level und unportabel stimmt schon. Wobei low-level echt praktisch ist. Low-level -> high-level geht immer ganz einfach, high-level -> low-level ist eher schwierig.

wxSkip

@ipsec: soll er doch DirectX zum Zeichnen verwenden (ok, das kann er nicht auf Linux portieren).
Aber OpenGL oder so was.

@nwp2: Wenn du nie von Low-Level auf High-Level umsteigst, wirds auch keinen interessieren, dass es einfacher geht.