-
Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
Erfahrungsaustauch zwischen C++ Programmieranfängern !?!
- Ersteller ThomasF
- Erstellt am
OP
Hi,
also die Literaturhinweise sind ja schon mal ganz ok ;-)
Aber in erster Linie würde ich auch gerne erfahren wie weit Ihr denn so beim lernen seid.
Also ich zum Beispiel bin wenn ich nach dem "C++ - Lernen und professionell anwenden" Buch gehe ungefähr bei Kapitel 14 (Methoden) auch wenn ich einige Punkte die in diesem Buch später kommen schon an anderer Stelle schon mitbekommen habe.
Ich "hänge" aber noch ein wenig im Umgang mit Pointern und Referenzen und brauche dort wahrscheinlich einfach ein wenig mehr Übung.
Zu diesem Zweck "spiele" ich im Augenblick ein wenig mit dem Thema "verkettete Listen" die ja viel mit Pointern arbeiten.
Vom reinen Verständnis bis zu diesem Punkt gibt es bei mir keine Probleme.
Ich nutze im übrigen das C++ Plugin von Eclipse, da ich zur Zeit noch keine GUI selber schreibe, ich hab mich aber auch schon mit Kdevelop und QT Designer versucht das aber auf später verschoben ;-)
So long
ThomasF
also die Literaturhinweise sind ja schon mal ganz ok ;-)
Aber in erster Linie würde ich auch gerne erfahren wie weit Ihr denn so beim lernen seid.
Also ich zum Beispiel bin wenn ich nach dem "C++ - Lernen und professionell anwenden" Buch gehe ungefähr bei Kapitel 14 (Methoden) auch wenn ich einige Punkte die in diesem Buch später kommen schon an anderer Stelle schon mitbekommen habe.
Ich "hänge" aber noch ein wenig im Umgang mit Pointern und Referenzen und brauche dort wahrscheinlich einfach ein wenig mehr Übung.
Zu diesem Zweck "spiele" ich im Augenblick ein wenig mit dem Thema "verkettete Listen" die ja viel mit Pointern arbeiten.
Vom reinen Verständnis bis zu diesem Punkt gibt es bei mir keine Probleme.
Ich nutze im übrigen das C++ Plugin von Eclipse, da ich zur Zeit noch keine GUI selber schreibe, ich hab mich aber auch schon mit Kdevelop und QT Designer versucht das aber auf später verschoben ;-)
So long
ThomasF
Also in C++ bin ich im Moment an einem Toten Punkt. Die Grundlagen (Schliefen, verzweigungen, File I/O, Klassen und Methoden) verstehe ich (teilweise auch durch andere Programmiersprachen), aber die Anwendung fehlt ein bißchen. Abgesehen davon gibts viele Unschönheiten die das Weitermachen schwierg machen (z.B. wie teile ich mein Programm sinnvoll in mehrere Teile (jede Klasse eine Datei wäre schön und dann die dazupassenden Headerfiles erstellen, aber dann klappts mit dem kompilieren nicht mehr richtig)). An einer GUI habe ich mich noch nicht versucht.
Mit Pointer komme ich klar nur weiß ich immer nicht wann es Sinn macht diese zu benutzen. Sollte man so viel wie möglich auf den Heap legen, oder nur "große" Objekte und einfache Variablen (int, char, etc.) auf dem Stack lassen?
Mit Pointer komme ich klar nur weiß ich immer nicht wann es Sinn macht diese zu benutzen. Sollte man so viel wie möglich auf den Heap legen, oder nur "große" Objekte und einfache Variablen (int, char, etc.) auf dem Stack lassen?
das ist ein sinnvolles Vorgehen, mit den Includes ist das so eine Sachenbkr schrieb:
nicht immer alle anderen Klassen includen sondern mit forward-Deklarationen arbeiten. (dann klappen auch zyklische Referenzen)ich lege nur das auf den Heap, das a/ zu viel Platz braucht oder b/ in anderen Kontexten gebraucht wird
TeXpert schrieb:das ist ein sinnvolles Vorgehen, mit den Includes ist das so eine Sachenbkr schrieb:
Nicht nur das, die Übersetzung wird schneller und das Modul wird insgesamt leichter.
TeXpert schrieb:
Genau da hapert es bei mir auch. Bei Kalva nutze ich wenig Pointer. Genaugenommen nur dort, wo ich in anderen KDE-Sourcen Vergleichbares gefunden habe. Wenn ich selber Pointervariablen anlege, hab ich schon öfters den Crashmanager herbeigezaubert :?
Ich bekomme so langsam ein Gefühl dafür, wann ich besser die Finger von Pointern lassen muss, aber so richtig verstanden hab ich das noch nicht. Das ist ein bisschen wie bei den ersten Fahrstunden... Wo fährt das Auto mit mir hin
?Wo man recht sicher Pointer verwenden kann ist, wenn man an einer eigenen Klasse einen Verweis auf bereits bestehende Objekte hinterlegen möchte (z.B. beim Erzeugen eines Widgets, welches man in ein anders einbettet. Das Widget bekommt dann z.B. im Konstruktor einen Pointer auf das Vaterwidget übergeben und speichert diesen in eine eigene Membervariable.
Auf eigene Datenkonstrukte (z.b. einem QString als Member) kann ein Pointer tödlich wirken. Schätze, man darf und u.U. sollte man es in bestimmten Fällen tun, muss dann aber für die Speicherverwaltung sorgen. Dazu fehlt mir noch das Verständnis, daher lasse ich das sein, es geht ja auch ohne Pointer.
Ui fein, ein eXpert(e) ... dann werd' ich mal anfangen Dich zu löchern ;-)
Ok, Forward kann ich noch nicht, muss ich gleich mal nachschauen was das macht.
Aber evtl. ist mein Problem auch wesentlich einfacher zu lösen. Ich wollte ein kleines Programm schreiben (das eigentlich im Prinzip nichts tut außer eine andere Datei zu includieren.
Erstmal die funktionierende Version
Wie gesagt das klappt bestens. Kompilieren mit g++ test.cpp und man erhalt eine funktonierende Datei.
Jetzt hab ich gelesen man sollte das eher mit Header Files machen. Also den Quellcode geändert.
Ergebnis. Kompilieren, bzw. genauer Linken schlägt fehl, weil er findet zwar die Headerdatei mit der Deklaration, nicht aber die Definition von "rechne". Man kann das zwar umgehen in dem man mit
kompiliert, aber das wird ja tierisch unpraktisch wenn man mal ein paar mehr Unterfuntkionen hat. Gibts da ne Lösung für?
Also ist die Idee -> Komplexe Objekte auf den Heap, normale Variablen auf den Stack durchaus praktikabel.
TeXpert schrieb:das ist ein sinnvolles Vorgehen, mit den Includes ist das so eine Sache
Ok, Forward kann ich noch nicht, muss ich gleich mal nachschauen was das macht.
Aber evtl. ist mein Problem auch wesentlich einfacher zu lösen. Ich wollte ein kleines Programm schreiben (das eigentlich im Prinzip nichts tut außer eine andere Datei zu includieren.
Erstmal die funktionierende Version
Code:
/* Datei: test.cpp */
#include <stdio.h>
#include "subdir/includeme.cpp"
int main() {
printf("test\n");
printf("%i\n", rechne(5, 6));
return 0;
}
/* Datei: subdir/includeme.cpp */
int rechne(int a, int b) {
return a + b;
}Wie gesagt das klappt bestens. Kompilieren mit g++ test.cpp und man erhalt eine funktonierende Datei.
Jetzt hab ich gelesen man sollte das eher mit Header Files machen. Also den Quellcode geändert.
Code:
/* Datei: test.cpp */
#include <stdio.h>
/* Hier ist was anders von includeme.cpp nach includeme.h */
#include "subdir/includeme.h"
int main() {
printf("test\n");
printf("%i\n", rechne(5, 6));
return 0;
}
/* Datei: subdir/includeme.h */
int rechne(int, int);
/* Datei: subdir/includeme.cpp */
#include "includeme.h"
int rechne(int a, int b) {
return a + b;
}Ergebnis. Kompilieren, bzw. genauer Linken schlägt fehl, weil er findet zwar die Headerdatei mit der Deklaration, nicht aber die Definition von "rechne". Man kann das zwar umgehen in dem man mit
Code:
g++ test.cpp subdir/includeme.cppkompiliert, aber das wird ja tierisch unpraktisch wenn man mal ein paar mehr Unterfuntkionen hat. Gibts da ne Lösung für?
TeXpert schrieb:
Also ist die Idee -> Komplexe Objekte auf den Heap, normale Variablen auf den Stack durchaus praktikabel.
nbkr schrieb:
Mensch in meinem Hirn brumts, jetzt Quote ich mich schon selbst.
Forward = (auf gut Deutsch): Hallo Liebe Funktion X, Du musst Funktion Y benutzen, die hab ich aber erst nach dir erstellt, also stör dich nicht wenn Du sie noch nicht kennst, die kommt später noch im Quelltext.
Wenn ich es recht bedenke kenne ich dass noch von Turbo Pascal. Da gabs das auch.
Das Schönste an der Forwärtzdeklaration ist, dass andere, die Deinen Header verwenden, die Implementationsdetails der forwärtsdeklarierten Klasse gar nicht zu sehen bekommen. Der Compiler und der Linker werden es Dir mit sehr viel Geschwindigkeitszuwachs beim Übersetzen und Binden danken.
Nur Deine eigene Implementation (meineklasse.cpp) braucht dann das Include für die andere Klasse einzubinden.
Nur Deine eigene Implementation (meineklasse.cpp) braucht dann das Include für die andere Klasse einzubinden.
OP
nbkr schrieb:
Deshalb verwende ich Eclipse (Klickie Buntie *gg)
Nee mal im Ernst, ich möchte C++ lernen und mich erst mal nicht mit make Files und debug-Options auf der Komandozeile rumschlagen.
Wenn Du in Eclipse ein Projekt erstellst kannst Du ganz einfach mehrere Header oder Source Files hinzufügen und der make File wird automatisch erzeugt. Ich finde das sehr praktisch und ich kann mich ganz auf C++ konzentieren. Und die Bedienung von Eclipse oder KDevelop ist schnell gelernt. Wobei Kdevelop bei mir recht langsam ist.
nbkr schrieb:
Also Sinn macht es z.B bei den Verketteten Listen mit denen ich zur Zeit spiele. Du erzeugst z.B eine Instanz einer Klasse mit new und speicherst dabei die Adresse dieser Instanz in einem Pointer. Dieser Pointer wiederrum wird in der davor angelegten Instanz ab.
So erzeugst Du eine Reihe von Objecten wobei jedes Objekt auf seinen Nachfolger bzw. Vorgänger "zeigt".
1 -> 2 -> 3 -> 4 usw.
Es gibt aber bestimmt noch andere Verrwendungen ...
So long
Thomas
also jetzt mal langsam
1. ein
ist ein don't
dafür gibts Header-Dateien.
2. Du Programmierst in C und nicht in C++
3. das macht man so:
run.c
calc.h:
calc.c:
Für dieses Problem brauchst Du noch keine Forward-Deklaration, dazu reicht es die Funktion normal zu deklarieren (das findet in calc.h statt)
1. ein
Code:
#include "subdir/includeme.cpp"dafür gibts Header-Dateien.
2. Du Programmierst in C und nicht in C++
3. das macht man so:
run.c
Code:
#include <stdio.h>
#include "calc.h"
int main() {
printf("test\n");
printf("%i\n", rechne(5, 6));
return 0;
}calc.h:
Code:
#ifndef __CALC_H__
#define __CALC_H__
int rechne(int a, int b);
#endifcalc.c:
Code:
#include "calc.h"
int rechne(int a, int b) {
return a + b;
}Für dieses Problem brauchst Du noch keine Forward-Deklaration, dazu reicht es die Funktion normal zu deklarieren (das findet in calc.h statt)
ThomasF schrieb:
IDEs sind nichts für mich. Zumindest nicht, wenn ich eine Sprache neu lerne. Die legen zuviele Files an von denen ich nicht weiß wofür die gut sind. Wenn ich mal Durchblick habe kann ich immer noch eine IDE verwenden. Abgesehen davon: In Eclipse kann ich meinen Lieblingseditor gVim nicht nutzen ;-)
ThomasF schrieb:
flashce Vorgehensweise
1. Du brauchst nicht mal ein Makefile, einfach alles in einem Verzeichnis und dann:
Code:
$ g++ *.cpp -o foo
Code:
$ gcc *.c -o foound Pointer sind das Übelste und beste bei C und C++
TeXpert schrieb:
Ok, soweit war ich schon -> sie oben. Die Frage ist jetzt. Wie mach ich mir das am Einfachsten mit dem Kompilieren?. Mit dem Konstrukt geht ein einfaches
g++ run.c
ja nicht mehr. Weil der Compiler die Funktion rechne nicht findet, weil die ist ja in calc.c und die wird in run.c nirgends includiert (nur eben calc.h). Mit
g++ run.c calc.c
gehts wieder. Aber wenn man den Sourcecode dann vielleicht noch in ein paar Unterordner verteilt (der Übersicht halber) hat man irgendwann ein g++ Aufruf der über 3 Zeilen geht. Dienen dafür die Makefiles?
nbkr schrieb:
...zwar nicht gVim sondern kVim, aber einen eingebetteten VI bietet zumindest kdevelop (optional, default ist kate) ;-)
Ich finde es kommt ganz auf die Art des Projektes an. Für ein kleines Konsolentool mit wenigen Sourcedateien ist eine IDE sicher zu heftig.
Für ein Projekt mit vielen Sourcen, vor allem wenn Metasourcen dabei entstehen, ist so eine IDE schon sehr hilfreich. Wer Qt- oder auch richtige KDE-Anwendungen schreiben möchte, dem kann ich KDevelop sehr emfehlen, schon wegen der vielen Projekt-Templates und der sehr guten Integration der Dokus (Referenzen der Klassenbibliotheken für KDE, Qt, GTK(++), C++ u.s.w.). Sehr schön ist auch die Möglichkeit, eine Klasse im Sourcecode zu markieren und die passende Dokumentation per Auswahl aus dem Kontextmenü suchen und öffnen zu lassen. Die Integration des (angepassten) QtDesigners fürs RAD ist auch sehr gut.
Prinzipiell stimme ich Dir zu was IDEs angeht, aber gerade
bei QT kann man mit minimalem Aufwand auch ohne arbeiten. Ein qmake-Script schreiben (dazugibts genug Templates) einfach die sourcen einbosseln (kann man auch mit find auf der Shell machen) und das normale Makefile wird generiert.
Denn an sich sind IDEs klasse, aber ich bin bein Lernenden eher etwas konservativ lieber erst mal zu Fuß lernen, dann versteht man die Zusammenhänge besser...
taki schrieb:
bei QT kann man mit minimalem Aufwand auch ohne arbeiten. Ein qmake-Script schreiben (dazugibts genug Templates) einfach die sourcen einbosseln (kann man auch mit find auf der Shell machen) und das normale Makefile wird generiert.
Denn an sich sind IDEs klasse, aber ich bin bein Lernenden eher etwas konservativ
lieber erst mal zu Fuß lernen, dann versteht man die Zusammenhänge besser...TeXpert schrieb:ich bin bein Lernenden eher etwas konservativ
Alles eine Sache der Prioritäten
Meine war es, eine Anwendung zu schreiben und dabei mehr nebenbei zu lernen. Dafür, dass ich vorher ::null() Erfahrung mit C++ hatte (sogar eher durch COBOL und übleres vorbelastet bin), ist Kalva schon ziemlich gut herangewachsen. Damit wäre ich ohne IDE definitiv nicht fertig geworden... Wäre der Lerneffekt bei mir an oberster Stelle gewesen, gebe ich Dir recht. Aber ich muss gestehen, dass ich zu faul für den langen Weg bin. Ich brauche erst mal ein par Erfolgserlebnisse, damit der Spaß nicht zu kurz kommt. Erst danach knie ich mich tiefer ins Zeug. ok, das kommt aus meinen Tutoriums-Zeiten... ich hab schon zu Studienzeiten üble Erfahrungen mit Code gemacht, der so entwickelt wurde und dann fortgesetzt werden sollte. Ich habs auch so gelernt besser: ich habs aus den Fehlern gelernt, aber in den Tutorien hab ich dann doch eher auf der konservativen Seite angefangen...