Diese Frage richtet sich vor allem an hier anwesende C++ Freaks, die noch etwas freie Zeit haben. :) Habe mich entschieden, mit C++ anzufangen und bin nun auf der Suche nach einer guten Entwicklungsumgebung/Toolchain, die möglichst frei verfügbar ist und für die ich hier im Forum Hilfe bekommen kann wenn irgendwas nicht so funktioniert wie ich es mir vorstellen. Der alte Thread ist inzwischen sehr lang, unübersichtlich und wird wahrscheinlich nicht mehr von vielen gelesen, deswegen ein neuer für speziell C++.
Und ich fahre mit KDevelop fort. ;) Außerdem rate ich dem TO einfach mal was zu machen statt vier Jahre lang nach dem perfekten Set von Tools zu suchen.
Ich habs vergessen reinzuschreiben - diesmal bitte wirklich keine Frameworks. Bibliotheken, die man für irgendwas tolles gebrauchen kann, gerne in Hülle und Fülle, aber keine Frameworks!
Scheint für dich ziemlich schwierig zu sein, zu Potte zu kommen: "Grafikprogrammierung C++ oder C#" Beitrag "Grafikprogrammierung C++ oder C#" "Welche Programmiersprache für Windows-Oberfläche?" Beitrag "Welche Programmiersprache für Windows-Oberfläche?" Such dir lieber jemanden, der dein Spiel für dich programmiert.
@Helmut Sach ma kannst Du es nicht lassen, mir diesen Thread zuzumüllen?! Was hast Du denn für eine Ahnung was ich programmieren will? Wer gibt Dir das Recht mir vorzuschreiben was ich zu tun, zu lassen oder zu lernen habe?! Sorry, ich WILL halt nunmal in C++ reinschauen und ich denke/hoffe ich find hier auch Leute, die mir das ermöglichen. @Scummos Ja, ist schwer, das Richtige zu finden. :-/ Will mir mal anschauen was mit reinem C++ und evtl. ein paar nötigen Bibliotheken möglich ist und was nicht. Danach bin ich wieder ein bißchen schlauer.
Du wist auf jeden Fall durch diesen Thread hier nicht schlauer werden. In den bisherigen fünf wurde wirklich alles zu dem Thema gesagt. (Trotzdem kann ich natürlich keine Gelegenheit auslassen, Werbung für KDevelop zu machen ;))
>Sach ma kannst Du es nicht lassen, mir diesen Thread zuzumüllen?!
Wenn du aufhörst, das Forum mit fast identischen Fragen zuzumüllen.
> (Trotzdem kann ich natürlich keine Gelegenheit auslassen, Werbung für > KDevelop zu machen ;)) Na gut, das sei Dir gegönnt. ;) Aber kannst Du auch sinnvoll begründen wieso ich nacher nicht schlauer sein sollte als vorher? Liegts an dem Problem "Thread" oder an dem Problem "C++"?
Es liegt daran, dass verschiedene Leute verschieden arbeiten, und verschiedene IDEs und Editoren bevorzugen. Dasselbe gilt für Toolkits, Programmiersprachen, ... Du kannst allein durch rumfragen, auch bei Leuten, die du für kompetent hältst, nicht rausfinden, mit was du gut arbeiten können wirst. Das kannst du nur, indem du einfach mit irgendetwas anfängst, und wenn du feststellst "nee, suckt weil X", zu etwas anderem wechselst. Bis du ein Set von Tools gefunden hast, die für dich geeignet sind. Das können auch 20 Threads zu "welche IDE ist die beste -- welche Sprache ist die beste -- welches Toolkit ist das beste" nicht ersetzen, ja, die können nichtmal besonders viel dabei helfen. Das ist denke ich auch der Grund, warum einige Leute hier etwas genervt sind ;)
qt-creator+gcc funktioniert bestens für reine C++ Entwicklung :)
Ben _ (burning_silicon) schrieb > Ich habs vergessen reinzuschreiben - diesmal bitte wirklich keine > Frameworks. Aber Windows GUI-Programme willste doch schreiben oder etwa nicht?
Adler schrieb: > Ben _ (burning_silicon) schrieb > >> Ich habs vergessen reinzuschreiben - diesmal bitte wirklich keine >> Frameworks. > > Aber Windows GUI-Programme willste doch schreiben oder etwa nicht? Frag lieber nicht.
> Aber Windows GUI-Programme willste doch schreiben oder etwa nicht?
Nicht nur, aber die direkte Frage würde ich bejahen.
Es sind viele Sachen in C++ geschrieben, die auch GUI unter Windows
können. Also muß es doch irgendwie funktionieren, gibts irgendeinen
plausiblen Grund wieso das nicht mehr mit C++ gemacht werden sollte,
auch wenns mit Frameworks evtl. wirklich schneller geht?
@Scummos
Da magst Du Recht haben. Das Problem ist aber, daß zB. wenn ich ein
Problem mit Compiler X habe und nach einer Lösung frage bestimmt drei
Mann ankommen und meckern "Klar, daß Du damit Probleme hast, Compiler Y
ist doch Welten besser!" oder "Da kann ich Dir auch nicht helfen weil X
nutzt doch keine Sau."
Meine, nochmal meine simple Frage nach einem Fenster mit ein paar
anklickbaren Linien drin, so quasi als fortgeschrittenes Hallo-Welt zum
draus lernen - die Frage ist komplett im Sande verlaufen.
Ben _ schrieb: > Es sind viele Sachen in C++ geschrieben, die auch GUI unter Windows > können. Also muß es doch irgendwie funktionieren, gibts irgendeinen > plausiblen Grund wieso das nicht mehr mit C++ gemacht werden sollte, > auch wenns mit Frameworks evtl. wirklich schneller geht? Die Frage haben wir schon oft diskutiert, und sie ist auch schon oft gut erklärt worden. Ich glaube, du kannst die Antwort nicht verstehen, ohne selbst mal eine Weile mit C++ gearbeitet zu haben. Siehe zum Beispiel Beitrag "Re: Grafikprogrammierung C++ oder C#" ;) > @Scummos > Da magst Du Recht haben. Das Problem ist aber, daß zB. wenn ich ein > Problem mit Compiler X habe und nach einer Lösung frage bestimmt drei > Mann ankommen und meckern "Klar, daß Du damit Probleme hast, Compiler Y > ist doch Welten besser!" oder "Da kann ich Dir auch nicht helfen weil X > nutzt doch keine Sau." Das wird aber immer so sein, egal wie lange du rumfragst. Das ist schließlich das Internet hier. Es gibt dann zwei Möglichkeiten 1) du wechselst zu Y und testest ob der wirklich besser ist 2) du weißt schon, dass Y auch Mist ist und ignorierst diese Leute einfach > Meine, nochmal meine simple Frage nach einem Fenster mit ein paar > anklickbaren Linien drin, so quasi als fortgeschrittenes Hallo-Welt zum > draus lernen - die Frage ist komplett im Sande verlaufen. Siehe oben. Die Frage ist nicht so banal, wie sie sich anhört. Grüße, Sven
Dann frag ich mal direkt. Würdest Du so ein Beispiel hinkriegen, wenn ja, womit? Kennt sich wer mit SDL aus, kommt das mit C++ klar?
libsdl.org schrieb:
> ... SDL is written in C, but works with C++ natively ...
Dritter Absatz, direkt auf der Startseite.
Hab nur den Wiki Artikel gelesen. @Scummos Arbeiten diese Funktionen zur Laufzeit, sprich kann ich zB. eine Linie oder sonstwas zu einer bereits bestehenden Ansammlung dazuzeichnen oder dient das nur zur Erstellung eines statischen Bildschirms? Ich find im Moment diese ganzen Bezeichner bei Qt&Co verwirrend und nervend.
Hä? "Laufzeit" bedeutet "wenn das Programm ausgeführt wird". Natürlich werden die Funktionen ausgeführt, wenn das Programm läuft -- der Compiler wird das ja kaum übernehmen. Was ist eine "bereits bestehende Ansammlung"? Eine existierende QGraphicsScene? Ja, da kann man was dazuzeichnen. Ein Bild? Da kann man auch was dazuzeichnen. Grüße, Sven
Hmm vielleicht denke ich zu primitiv. Ich denke im Moment nicht an irgendwelche Layer, sondern eine ganz einfache Bitmap, nur einen einzigen Layer. Also Punkt X Y hat die Farbe Z. Wenn ich darauf zur Laufzeit einen Befehl SonstewasLine mit zwei Endpunkten A/B und einer Farbe C anwende, erwarte ich, daß sich umgehend in dieser Bitmap die Bildpunkte zwischen A und B mit der Farbe C füllen... Ist das korrekt oder funktioniert das bei solchen Programmen anders?
Wurde Code::Blocks schon genannt? Gibt's für Windos und Linux und Mac, ist nicht so ausgeblasen wie Eclipse, funktioniert mit zig Compilern, ...
Ben _ schrieb: > Hmm vielleicht denke ich zu primitiv. Ich denke im Moment nicht an > irgendwelche Layer, sondern eine ganz einfache Bitmap, nur einen > einzigen Layer. Also Punkt X Y hat die Farbe Z. Wenn ich darauf zur > Laufzeit einen Befehl SonstewasLine mit zwei Endpunkten A/B und einer > Farbe C anwende, erwarte ich, daß sich umgehend in dieser Bitmap die > Bildpunkte zwischen A und B mit der Farbe C füllen... Ist das korrekt > oder funktioniert das bei solchen Programmen anders? QGraphicsScene macht was anderes, das verwaltet nämlich die Objekte, die sich in der Scene befinden. Du kannst also eine Linie auch wieder löschen. Wenn du einfach nur Bitmaps malen willst, kannst du z.B. mit einem QPainter http://qt-project.org/doc/qt-4.8/qpainter.html in ein QPixmap malen, oder vergleichbar bei anderen Bibliotheken.
Ben _ schrieb: > Hmm vielleicht denke ich zu primitiv. Ich denke im Moment nicht an > irgendwelche Layer, sondern eine ganz einfache Bitmap, nur einen > einzigen Layer. Also Punkt X Y hat die Farbe Z. Wenn ich darauf zur > Laufzeit einen Befehl SonstewasLine mit zwei Endpunkten A/B und einer > Farbe C anwende, erwarte ich, daß sich umgehend in dieser Bitmap die > Bildpunkte zwischen A und B mit der Farbe C füllen... Ist das korrekt > oder funktioniert das bei solchen Programmen anders? Windows GUI-Programmierung funktioniert anders. Du musst Deine Denkweise umstellen. Dein Programm ruft nichts auf, Du wirst aufgerufen, bekommst Window Messages und musst diese schnellstmöglich bearbeiten. Die Window Messages können angeklickte Menüpunkte, Tastdrücke, Mausbewegungen, angeklickte Buttons oder ein minimiertes oder maximiertes Programmfenster sein. Oder auch ein WM_PAINT, d.h. die Aufforderung an Dich, Dein Fenster neu zu zeichnen. In diesem Fall musst Du Dir den zum Fenster gehörenden Device Context holen und Deine Linie in den DC reinmalen. Die Windows API ist C. Das ++ ist nicht erforderlich. Früher gabs "Programming Windows" von Charles Petzold. Die neueste Version ist aber für C# und für Dich nutzlos. Versuch eine alte Ausgabe zu bekommen und arbeite die durch. fchk
Naja, man kann ja einfach das Pixmap im Hintergrund irgendwo haben, und wenn ein PaintEvent kommt, zeigt man einfach das Pixmap an. Dann hat man die von Ben beschriebene Situation.
Heißt, bevor ich wirklich was malen darf muß ich warten bis Windows es "sehen will"? Woher weiß es wann ich was malen will? Und wenn ein anderes Fenster den Platz meines Fensters auf dem Bildschirm beansprucht, stellt Windows den überschriebenen Teil nicht von selbst wieder her wenn mein Fenster wieder in den Vordergrund kommt?
Dein Programm wartet i.d.R. bis der Window Manager sagt "das Fenster ist jetzt sichtbar, mal' mal", und dann zeichnet es seinen Kram. Das ist auch sinnvoll, denn dann zeichnet das Programm zum Beispiel nicht die ganze Zeit seine Widgets neu, während es minimiert ist. Und nein, der überschriebene Teil wird nicht von selbst wiederhergestellt -- erst, wenn dein Programm das nächstes mal den Bildschirm neu zeichnet. Das sieht man ja auch ganz gut an diesen lustigen Zeichenfehlern, die auftreten, wenn der GUI-Thread irgendeines Programms mal hängt. Grüße, Sven
Na das ist ja übel. Meine, das mit den Messages war mir klar, aber daß ich jederzeit mein eigenes Fenster komplett wiederherstellen können muß find ich kacke. Mal angenommen ich male 'ne Mandelbrotmenge und irgendwas übermalt mir einen Teil des Fensters - dann kann ich von vorne anfangen, wenn ich die Ausgabe nirgendwo gepuffert habe?
Naja deshalb malst du ja auch nicht in den Buffer von der Grafikkarte, sondern in ein QPixmap oder sowas. Dann kannst du den Inhalt wiederherstellen, indem du einfach das Pixmap nochmal anzeigst. Aber ja, wenn du die paint()-Methode von, keine Ahnung, irgendeinem Widget neu implementierst, dann geht jedes Mal alles verloren, was vorher da war, also jeder Aufruf der Funktion muss das komplette Bild neu zeichnen. Macht man ja aber auch nicht, wenn das Zeichnen viel Aufwand ist. Schon deshalb, weil das Zeichnen dann im GUI-Thread passiert, das heißt, während gezeichnet wird, blockiert deine Anwendung und zeichnet das Fenster zum Beispiel nicht neu, wenn der Benutzer es skaliert oder so.
Das sind aber Probleme, die ich bei Qt, C# usw. auch hätte, oder? Ist das beim Vollbildmodus genauso?
Ben _ schrieb: > Dann frag ich mal direkt. Würdest Du so ein Beispiel hinkriegen, wenn > ja, womit? > > Kennt sich wer mit SDL aus, kommt das mit C++ klar? als Beispielprojekt C++ mit SDL1.2 sei http://www.flarerpg.org/ genannt
Ben _ schrieb: > Das sind aber Probleme, die ich bei Qt, C# usw. auch hätte, oder? Das sind keine Probleme. So funktioniert's halt einfach. Ich sehe auch echt kein Problem hier... in welchem Fall soll das denn ein Problem sein? Aber ja, das funktioniert immer so, weil das der Window Manager vom Betriebssystem so macht (von jedem mir bekannten Betriebssystem zumindest)
Ben _ schrieb: > Na das ist ja übel. > > Meine, das mit den Messages war mir klar, aber daß ich jederzeit mein > eigenes Fenster komplett wiederherstellen können muß find ich kacke. Diese Designentscheidung kommt aus den Anfangstagen, als Speicher knapp war. Und sie hat sich bewährt. > Mal angenommen ich male 'ne Mandelbrotmenge und irgendwas übermalt mir > einen Teil des Fensters - dann kann ich von vorne anfangen, wenn ich die > Ausgabe nirgendwo gepuffert habe? Du kannst ja auch problemlos in einen offscreen Device Context malen, den Du dann im WM_PAINT Handler nur noch mit BitBlt() ins Window kopieren musst. fchk
Wie oft kommt denn so eine Paint-Message?
EDIT:
> als Beispielprojekt C++ mit SDL1.2 sei http://www.flarerpg.org/ genannt
Gar nicht schlecht, aber ich fürchte um sich da als C++ Anfänger
reinzuarbeiten schon zu groß, zu komplex, oder?
Das kommt auf alles mögliche an, aber wenn mit so 30-60 Events pro Sekunde muss man schon rechnen, würde ich sagen.
Muß ich mich auch noch drum kümmern in welchen Bereich des Bildschirms ich den Puffer reinkopieren muß wenn das Fenster verschoben wird usw.? Ich glaub langsam ich bleib bei PHP ... Oder ich bräuchte wirklich ein "fertiges" Programm dieser Art als Grundgerüst zum Lernen und erweitern.
Vielleicht wird dir langsam klar, warum man nicht mit Assembler in den Grafikbuffer schreibt, sondern ein geeignetes Framework benutzt. Wenn du zum Beispiel Qt verwendest, musst du dich um sowas nicht kümmern, wenn du nicht willst. QGraphicsScene lässt dich deine Striche zeichnen und kümmert sich selbst um den ganzen PaintEvent-Kram.
Klaue ich Dir viel von Deiner Zeit wenn ich Dich bitte so ein Beispielprogramm zu schreiben, nur damit ich's mir mal anschauen kann wie das aussieht und wie's funktioniert? Mit Assembler hat das nicht viel zu tun. Ich kann in Assembler ja auch Konsolen-Anwendungen schreiben und brauch mich da kein bißchen um das Fenster zu kümmern. Bzw. ich kann in diesem Fenster ausgeben was ich will und Windows kümmert sich um den Rest.
Ben _ schrieb: > Wie oft kommt denn so eine Paint-Message? > > EDIT: >> als Beispielprojekt C++ mit SDL1.2 sei http://www.flarerpg.org/ genannt > Gar nicht schlecht, aber ich fürchte um sich da als C++ Anfänger > reinzuarbeiten schon zu groß, zu komplex, oder? Anbei eine Datei um ein Fenster darzustellen. (33 Zeilen) zu kompilieren mit:
1 | g++ simpletest.c -I /usr/include/SDL/ -lSDL |
Naja wenn man komplizierte Dinge will, muss man viel programmieren. Wenn du nur ein paar Buttons, Textboxen etc haben willst, wäre QT vielleicht doch besser. ;)
Stefanie B. schrieb: > zu kompilieren mit: g++ simpletest.c -I /usr/include/SDL/ -lSDL Well on unix that is... Ich wüsste nicht stante pede wie man soetwas unter Windows kompiliert.
Hier in Qt, 8 Zeilen. :D
1 | #include <QtGui/QApplication> |
2 | #include <QtGui/QLabel> |
3 | |
4 | int main(int argc, char** argv) { |
5 | QApplication app(argc, argv); |
6 | QLabel label("Hello World!"); |
7 | label.show(); |
8 | return app.exec(); |
9 | }
|
g++ -o test test.cpp $(pkg-config --libs --cflags QtGui) > Well on unix that is... Ich wüsste nicht stante pede wie man soetwas > unter Windows kompiliert. Das ist ein Mysterium, das weiß niemand. ;)
Sven, vermutlich ist Dir noch nicht klar, daß Du gerade das Todesurteil
Deiner Freizeit unterschrieben hast... **fg** ;)
Ich werd mal sehen wo ich Qt für Windows herbekomme und schaue mir das
mal an. Wenn ich damit klarkommen sollte dann bleibt C++ den Anwendungen
vorbehalten, die keine Fenster brauchen.
EDIT:
> QT-Syndrom, eine seltene lebensgefährliche Krankheit
Na das fängt ja gut an!
481 Megabyte ?! oO Sind die irre? Na das wird mich ein wenig Zeit kosten, in meiner Gegend gibts kein VDSL... :(
Angehängte Dateien:
-
test.png
5,5 KB
Hier ein tolleres Beispiel mit Linien und Rechtecken. Weil mir grad langweilig ist.
1 | #include <QtGui/QApplication> |
2 | #include <QtGui/QGraphicsScene> |
3 | #include <QtGui/QGraphicsView> |
4 | #include <QtGui/QMainWindow> |
5 | #include <QtGui/QMenuBar> |
6 | #include <QtGui/QAction> |
7 | |
8 | int main(int argc, char** argv) { |
9 | QApplication app(argc, argv); |
10 | QMainWindow mainwin; |
11 | QGraphicsScene scene; |
12 | QGraphicsView view; |
13 | view.setScene(&scene); |
14 | mainwin.setCentralWidget(&view); |
15 | |
16 | QPen pen; |
17 | pen.setColor(Qt::red); |
18 | scene.addLine(0, 0, 30, 30, pen); |
19 | pen.setColor(Qt::blue); |
20 | scene.addRect(15, 15, 70, 70, pen); |
21 | |
22 | QMenu* appMenu = mainwin.menuBar()->addMenu("Application"); |
23 | QAction quit("Quit", &mainwin); |
24 | appMenu->addAction(&quit); |
25 | QObject::connect(&quit, SIGNAL(triggered(bool)), &mainwin, SLOT(close())); |
26 | |
27 | mainwin.show(); |
28 | return app.exec(); |
29 | }
|
Und hier die CMakeLists.txt:
1 | project(testproject) |
2 | add_executable(test test.cpp) |
3 | find_package(Qt4 REQUIRED) |
4 | include_directories(${QT_INCLUDE_DIR})
|
5 | target_link_libraries(test ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES})
|
So, das war's jetzt aber mit Beispielprogrammen für heute ;) In dem Fall kümmert sich jetzt zum Beispiel Qt komplett um das Zeichnen, wenn du das Fenster skalierst, oder minimierst, oder sontwas machst.
> Sven B. Hey, danke. Gerade eben wollte ich nach einem einfachen Beispiel fragen, weil das Example von Qt selbst ( http://qt-project.org/doc/qt-4.8/qpainter.html ) deutlich zu überladen ist.
Ja, die Beispiele aus den Qt Docs sind nur hilfreich, wenn man schon eine funktionierende Anwendung hat und da was einbauen will, da stehen nie komplette Anwendungen. Das ist einerseits natürlich sinnvoll, weil man das meist nicht braucht, aber andererseits am Anfang etwas anstrengend ;)
Joo, wird eh noch dauern bis ich damit rumprobieren kann. Klebe bei 20% vom Download. Verwendest Du das eigentlich unter Windows oder Linux?
QT ist unter Windows recht einfach. Einfach das passende Packet unter http://qt-project.org/downloads herunterladen und installieren. Dann QTCreator starten und das gewünschte Projekt öffen, bauen, starten :) Ich benutze auch Linux.
Und wenn Du wissen willst, wie das ganze komplett ohne QT oder ein anderes Framework geht, lies das hier: http://pronix.linuxdelta.de/C/win32/win32_1.shtml
Ganz so einfach ists dann doch nicht... Svens Beispiel einfach mal zu compilieren versucht ergibt: mainwindow.obj:-1: Fehler:LNK2005: _main ist bereits in main.obj definiert. main.obj:-1: Fehler:LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: virtual __thiscall MainWindow::~MainWindow(void)" (??1MainWindow@@UAE@XZ)" in Funktion "_main". main.obj:-1: Fehler:LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: __thiscall MainWindow::MainWindow(class QWidget *)" (??0MainWindow@@QAE@PAVQWidget@@@Z)" in Funktion "_main". debug\test.exe:-1: Fehler:LNK1120: 2 nicht aufgelöste externe Verweise.
Hey, nicht so vorwurfsvoll... oO Ich hab Qt installiert, hab Deinen Sourcecode da reingeguttenbergt, das Format bei den Includes angepasst und sonst nix. #include <QApplication> usw. Das Ding erstellt irgendwie eine main.cpp und eine mainwindow.cpp, kommt mir doppelt vor.
Ja, dann hast du wohl zwei Anwendungen zusammengeklebt, die man nicht zusammenkleben sollte ;) Kann ich jetzt so aus der Ferne nicht debuggen... wahrscheinlich kannst du die mainwindow.cpp einfach löschen, und auch aus dem qmake-project file entfernen, u.U. geht es dann schon.
Ich programmiere momentan eine kleine 2D Engine für Plattformer Games in C++. Ich benutze Visual Studio Express 2010 Ben _ schrieb: > Dann frag ich mal direkt. Würdest Du so ein Beispiel hinkriegen, wenn > ja, womit? > > Kennt sich wer mit SDL aus, kommt das mit C++ klar? Anstatt der SDL würde ich dir zu SFML raten. Davon ab das die SFML viel mehr Features hat, ist SFML in C++ geschrieben und hat eine komplett Objektorientierte Libary. Das macht vieles einfacher. SFML hat 5 Module (System, Window, Graphics, Network, Audio) welche wiederrum die entsprechenden Klassen beinhalten. Sehr übersichtlich im Gegensatz zu Qt. Dazu ist die SFML sehr mächtig - es lassen sich wirklich jegliche Art von 2D Spielen implementieren und die Einbindung von OpenGL ist möglich. http://www.youtube.com/watch?v=XcVxSSIdiAE Auf www.sfml-dev.org gibt es auch Tutorials zu den einzelnen Modulen und auf Youtube findet man auch einige nützliche Videos die helfen die einzelnen Klassen kennenzulernen und generell einen Einstieg in die Grafikprogrammierung zu finden.
Merkus schrieb: > Anstatt der SDL würde ich dir zu SFML raten. Davon ab das die SFML viel > mehr Features hat, ist SFML in C++ geschrieben und hat eine komplett > Objektorientierte Libary. Das macht vieles einfacher. SFML hat 5 Module > (System, Window, Graphics, Network, Audio) welche wiederrum die > entsprechenden Klassen beinhalten. Sehr übersichtlich im Gegensatz zu > Qt. Dazu ist die SFML sehr mächtig - es lassen sich wirklich jegliche > Art von 2D Spielen implementieren und die Einbindung von OpenGL ist > möglich. Hi Markus ^^, also Ben hat sich Gott Lob für QT entschieden :-) dort gibt es OpenGL2 Widgets, also schmeiss die lib bitte von dir weg !!! Die macht keinen sinn zusammen mit QT. Man könnte noch vll Boost erwähnen, für mehr Portabilität, also in Richtung anderer GUI !!! Oder von mir aus für 3D Sachen Oger :) Aber i denke Ben sollte erstmal mit QT klar kommen :-) P.S: BEN gute Entscheidung bleib dabei :-)
Und Apropo, Sven in allen Ehren !!! Aber das ist echt keine gute Art Leuten c++ Code zu zeigen -.- Alles in der main -.- NENENE P.S: ja kleines Programm , aber bitteeeeeeee, so Code nie jemanden zeigen !!!
@ BEN poste dein komplttes Projekt als .zip Dann wird dir geholfen ;-) MFG
>Sven in allen Ehren !!! >Aber das ist echt keine gute Art Leuten c++ Code zu zeigen -.- Hi Jean Player, könntest Du den Code von Sven mal so posten, wie er Deiner Meinung nach aussehen sollte?
LOL jetzt prallen wieder verschiedenste Programmierstile und Vorlieben aufeinander. Hab's mit ein wenig rumprobieren geschafft, das Ding zu kompilieren (die Funktion main aus der main.cpp rausgeschmissen, vermutlich auch nicht die saubere Art, aber für nen Test okay), krieg dann aber beim Aufruf außerhalb der Entwicklungsumgebung die Meldung, daß qt5widgetsd.dll nicht gefunden werden kann.
Leute, ihr wohl echt zu viel Zeit? ^^ Ich würde Folgendes vorschalgen: Ben postet seine Requirements-Spezifikation (als Word Dokument oder ähnliches). Wir setzen dann ein Git-Repo auf, und entwickeln ihm das Programm. Dann hört endlich diese nervige Fragerei auf ;-) Mal im Ernst: ich hab das Gefühl der Autor des Threads bemüht sich kein bisschen, mal selber etwas auszuprobieren. Jede Kleinigkeit muss hier vorgekaut werden. Aus eigener Erfahrung weiß ich, dass man sowas auch sehr gut autodidaktisch lernen kann. Das Netz ist zudem voll von hervorragenden Tutorials zu deisen Themen...
Jean Player schrieb: > Und Apropo, > Sven in allen Ehren !!! > Aber das ist echt keine gute Art Leuten c++ Code zu zeigen -.- > Alles in der main -.- Ich bin sehr gespannt auf deine bessere Version des Programms. Ben _ schrieb: > LOL jetzt prallen wieder verschiedenste Programmierstile und Vorlieben > aufeinander. Einfach ignorieren. > Hab's mit ein wenig rumprobieren geschafft, das Ding zu kompilieren (die > Funktion main aus der main.cpp rausgeschmissen, vermutlich auch nicht > die saubere Art, aber für nen Test okay), krieg dann aber beim Aufruf > außerhalb der Entwicklungsumgebung die Meldung, daß qt5widgetsd.dll > nicht gefunden werden kann. Das ist doch erstmal egal. Wenn es innerhalb der IDE funktioniert, ignorier' das einfach, das lässt sich dann später irgendwann leicht lösen. Gruß, Sven
Wenns sich leicht lösen lässt sag mal wie. :D Oki, werd mal ein wenig damit rumspielen.
Naja ist halt Windows, und das hab ich seit zehn Jahren nicht benutzt. Ich kann dir nur sagen, dass man es sicherlich leicht lösen kann, weil dein Setup ein absoluter Standard-Fall ist und es bei vielen Leuten funktioniert.
Ben: Ein guter Weg um eine Programmiersprache (oder ein Framework, eine Bibliothek etc.) zu erlernen ist das zugehörige Tutorial durchzuarbeiten. Einmal von Anfang bis Ende. Und dann weitere Male - solange bis man es verstanden hat. ;-)
@Ben So wie es aussieht hast du so gut wie keine Ahnung von C++. Lass das Qt erst mal in ruhe und lerne mal reines ANSI C++. Schreibe für den Anfang ein Paar Konsolen Programme. Folgende Punkte würde ich dir empfehlen: - was sind Header / Source Files - Header Guards - Datentypen (ist nicht ganz so einfach wie in PHP) - int float double char byte ... - Strings (auch mal die alten C like) - Komplexe Datentypen (instanzen von Klassen) - Kontrollstrukturen / Schleifen (schätze kennst du schon aus PHP) - if / else - switch case - for - while - do while - Arrays - Funktionen - vll auch Rekursionen - Emum (Aufzählung) - Pointer - Referenzen - Call by Value / Call by Reference (bei Funktionen) - Heap (new / delete) später auch vll mal OOP: - Klassen - Instanzen - Attribute - Methoden - usw... gibt noch viel mehr - Design Patters (Singleton Observer Factory ...) - Makefiles (Qt hat dafür z.B. qmake) wenn du diese Sachen mal drauf hast, dann kannst du schon mal einen Teil der Basics und kannst dich an Frameworks wie QT setzen. Als kleine Übung könntest du z.B. einene Labyrinth solver mit Backtracking programmieren.
Also ich finde ja dieses "du musst erstmal x y z a b c d e f lernen, bevor ich dir zugestehe, dass du das machen darfst, was du eigentlich willst" immer ein bisschen albern... Das erste, was ich mit C++ gemacht habe, war auch mit Qt und ich hab's auch gelernt. Man muss nun wirklich nicht unbedingt erstmal die C strings und diese schrecklichen C++-Arrays und den Factory Pattern verstehen, um damit was zu programmieren... Sicherlich sind das auf deiner Liste alles Sachen, die man sich irgendwann mal anschauen muss, aber das ist auch schon alles.
Na, wenn du das sagst... ich habe die C-Strings jedenfalls nie gebraucht, und vor allem nicht deren schreckliche API.
Man kann auch eine String-Klasse benutzen. Wie QString. Oder wenigstens std::string.
> ich habe die C-Strings jedenfalls nie gebraucht, und vor allem > nicht deren schreckliche API. Du meinst die char*? Wo haben die denn eine API? ;) Aber verkehrt ist es nicht, wenn man weiss, wie es geht. So ab und zu muss man ja doch mal Systemcalls anfassen... > std::string OMG. Das ist gegen QStrings ungefähr so wie Seeigel gegen rosa Plüschhase. Wenn man nix anderes hat, sind die std::strings sicher besser als das char*-Gefrickel, aber wenn man mal länger QStrings gemacht hat, tun die std::strings genauso weh wie char*...
Ähh, ja, sorry, das war Quark -- ich meinte die API vom std::string. ;) Du hast schon Recht, dass man wissen sollte, wie dieser char* Kram funktioniert, denn früher oder später stößt man schon mal drauf. Aber das ist sicherlich nicht das erste, was man sich anschauen muss, wenn man eh Qt benutzt. Grüße, Sven
Sven B. schrieb: > Das erste, was ich mit C++ gemacht habe, war auch mit Qt und ich hab's > auch gelernt. Man muss nun wirklich nicht unbedingt erstmal die C > strings und diese schrecklichen C++-Arrays und den Factory Pattern > verstehen, um damit was zu programmieren... Wen man vorher nur mit Scriptsprachen gearbeitet hat, sollte man sich wenigstens die Basics aneignen bevor man sich an dicke Framworks wie Qt setzt. Die Patterns, klar sind am anfang nicht nötig, aber für OOP ist es nicht verkehrt einige zu kennen. Qt benutz auch einige Patterns wie z.B. Observer (Signale und Slots) und MVC (bei Qt das Model View Architecture).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.