Welche C++ Entwicklungsumgebung?

Dann fang ich mal mit Visual Studio Express an.

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!

oO ?!

@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 ;))

> (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 :)

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?

Ja, mit Qt. http://doc.qt.digia.com/stable/qgraphicsscene.html

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!

Qt ist C++ ;)

481 Megabyte ?! oO

Sind die irre? Na das wird mich ein wenig Zeit kosten, in meiner Gegend 
gibts kein VDSL... :(

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.

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?

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.

Was hast du denn gemacht?

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.

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.

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. ;-)

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