Erst C, dann C++?

[firewars]

Hallo,

an die, die damit Erfahrung gemacht haben: Ist es empfehlenswert, erst C, und dann C++ zu lernen, oder "kann" man gleich mit C++ anfangen?

Sicherlich ist C++ nicht um Welten verschieden, Unterschiede gibt es anscheinend aber dennoch zu Genüge.

Danke.

[Exxtreme]

Also wenn man mit c++ anfängt, dann sollte man IMHO das reine C schon können. Zwar sind die Philosophien ziemlich verschieden aber da C relativ "Lowlevel" ist, lernt man wie der Rechner tatsächlich die Programme abarbeitet. C++ ist wiederum abstrakter.

[zeckensack]

Ist beides ganz gut.

Man kann IMO ruhig gleich mit C++ anfangen, sollte sich aber je nachdem was man machen will auch mit der reinen C Standard-Library auseinandersetzen.

Also malloc, printf, arrays, fopen und Konsorten sind je nach Anforderung manchmal bessere Werkzeuge als new, std::string, STL-Container und iostream, und sind auch in C++ Projekten verfügbar, ist schließlich alles abwärtskompatibel.
Die Strukturhilfen von C++ (Klassen, Operatoren, überladene Funktionen) sollte man sich aber wirklich für alles angewöhnen, das hilft vor allem Fehler zu vermeiden und man kann solchen Code viel leichter in andere Projekte übertragen.

[Pitchfork]

Direkt C++. Zuerst kleine prozedurale Programme (also noch nicht viel objektorientierung). Alles mit der C++ Standardlib (also z.B. iostreams). Dann schrittweise in die Konzepte von OOP einarbeiten. Und eher zum Schluß kommt dann die generische Programmierung (templates).

Der Weg über C ist ein Irrweg. Die Konzepte sind zwar ähnlich wie bei C++ (wenn man OOP noch aussen vorläßt), aber man verschwendet Zeit mit eher sinnlosen Umwegen wie #defines, errorcodes statt exceptions, printf, etc.pp.

[firewars]

Hmm, schön und gut, aber wie habt ihr gelernt? Bücher gekauft? "Tutorials" gelesen? Ebooks?

Ich scheine nichts wirklich angemessenes (sprich für ziemliche Anfänger) zu finden :(

[Xmas]

Originally posted by Pitchfork
Direkt C++. Zuerst kleine prozedurale Programme (also noch nicht viel objektorientierung). Alles mit der C++ Standardlib (also z.B. iostreams). Dann schrittweise in die Konzepte von OOP einarbeiten. Und eher zum Schluß kommt dann die generische Programmierung (templates).

Der Weg über C ist ein Irrweg. Die Konzepte sind zwar ähnlich wie bei C++ (wenn man OOP noch aussen vorläßt), aber man verschwendet Zeit mit eher sinnlosen Umwegen wie #defines, errorcodes statt exceptions, printf, etc.pp.
Würde ich auch sagen.

[Nasenbaer]

Originally posted by firewars
Hmm, schön und gut, aber wie habt ihr gelernt? Bücher gekauft? "Tutorials" gelesen? Ebooks?

Ich scheine nichts wirklich angemessenes (sprich für ziemliche Anfänger) zu finden :(

Auf jedenfall ein Buch!
Ich habe zwar angefangen C/C++ mit dem Tutorials von www.volkard.de ( die alte Version ) allerdings hatte ich vorher auch schon einige Jahre mit (Object-)Pascal gearbeitet.

Hier findest du ne Diskussion zu Thema Bücher:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=46318

Mfg Nasenbaer

[Matrix316]

Originally posted by firewars
Hmm, schön und gut, aber wie habt ihr gelernt? Bücher gekauft? "Tutorials" gelesen? Ebooks?


Zwangsweise während des Studiums. ;)

Wir haben im ersten Semester die Grundlagen wie boolsche Algebra, Struktorierte Programmierung, Codierung und sowas gehabt. Im zweiten Semester war C dran, im dritten C++.

Aber ob C nötig ist...jedoch ist C++ einfacher zu erlernen wenn man C kann. ;)

Tutorials sind natürlich auch gut. Jedoch besonders empfehlenswert ist folgende Seite:

http://www.onlinelesen.de/

[piepre]

bin gerade dabei c zu lernen und bekomme schon albträume von den pointern ;(
aber ich würde mal sagen, dass es bestimmt nicht schadet erst c zu lernen, besonders wenn mal auf oop (vorerst) verzichten kann, jedoch ist cout viel kürzer als printf :)

[Exxtreme]

Originally posted by piepre
bin gerade dabei c zu lernen und bekomme schon albträume von den pointern ;(

Also Pointer sind eigentlich gar nicht schwer. Ich kann ehrlich gesagt die Aufregung darüber gar nicht verstehen.

[Winter[Raven]]

Also, ich persönlich denke man sollte erstmal mit C anfangen und danach zu C++ übergehen ... ! ;)

[piepre]

verstanden habe ich die pointer auch, aber void* und **p und ein pointer auf nen pointer der auf nen pointer zeigt, oder wie auch immer, is irgendwie nicht mein ding (noch nicht)...

[Matrix316]

Und ich finde Zeiger bzw. Pointer einerseits verwirrend und andererseits überflüssig. =)

[Xmas]

Originally posted by Matrix316
Und ich finde Zeiger bzw. Pointer einerseits verwirrend und andererseits überflüssig. =)
Seltsam. Ich finde Pointer leicht verständlich und in einigen Fällen notwendig ;)

[Wuzel]

Es kommt drauf an was man programmieren will, was einem Spass macht, auf welcher plattform etc.

So sind z.b auf fast allen Unixen C Kenntnisse unabdingbar, Apple hat Object C und auf MS kann man mit C wie C++, wobei hier die Empfehlung auf C++ liegt, da man hiermit besser mit Com ATL etc. klar kommt.

Auch klar -> Grafische Gui's alla 'Fensterln' werden ( biss auf Apple ) am effektivsten mit C++ geprogt, mit C haut man sich bei grösseren aktionen kräftig in den Finger.

Das was man für sich am ehesten braucht sollte man zuerst lernen, biss aufs Tüpfelchen, danach dann andere Sprachen.
Ein Unix Progger wird hier eher C lernen, dann C++ z.B.

[Vedek Bareil]

Originally posted by Matrix316
Und ich finde Zeiger bzw. Pointer einerseits verwirrend und andererseits überflüssig. =) nun ja, nützlich werden Pointer z.B. durch die in C/C++ bestehende enge Verknüpfung zu Arrays. Wenn ich etwa ein Array verwenden möchte, von dem ich zur Entwurfszeit noch nicht so genau weiß, wie groß es werden soll, kann ich z.B. folgendes machen:

double *pArray_of_double;
int ArraySize;

cout <<"Watt willst'n für ne Array-Größe hab'm?" <<endl;
cin >> ArraySize;

pArray_of_double = new double[ArraySize];

pArray_of_double[0] = 4711.0;
pArray_of_double[1] = 3.1415926;
...
pArray_of_double[ArraySize-1] = 1.e+100;

Anders gesagt kann man einen Pointer einfach so als Array "mißbrauchen" ;).

Ein anderes Anwendungsbeispiel wäre, daß du einer Funktion als Parameter irgendeine besonders viel Speicherplatz verschlingende Variable übergeben willst. Stattdessen übergibst du als Parameter dann einfach einen Pointer auf diese Variable, was Speicherplatz spart, da die Variable dann nicht bei der Übergabe kopiert werden muß. Zudem hat das den Vorteil (oder Nachteil, je nachdem wie man's sieht), daß die Variable von der Funktion verändert werden kann.
Zugegebenermaßen wurden zu diesem Zweck in C++ Referenzen eingeführt, so daß man dazu nicht unbedingt Pointer benötigt. Aber Referenzen bilden ja deren nähere Verwandtschaft ;)

[Matrix316]

In Java gibts keine Zeiger - und es geht auch. ;)

[Xmas]

Originally posted by Matrix316
In Java gibts keine Zeiger - und es geht auch. ;)
Kommt immer drauf an was du mit "es" meinst ;)

[Matrix316]

Originally posted by Xmas

Kommt immer drauf an was du mit "es" meinst ;)

Programmieren. ;)

[Demirug]

Zeiger sind in C++ ein notwendiges Sprachmittel um bestimmte verfahren implemtieren zu können. So sind in C++ zum Beispiel verkettet Listen ohne Zeiger nicht machbar.

Java braucht keine Zeiger weil per definition alle objekte auf dem Heap liegen und damit jeder verweis auf ein Objekt automatisch ein Zeiger ist von dem man natürlich nichts merkt.

[piepre]

Originally posted by Demirug
So sind in C++ zum Beispiel verkettet Listen ohne Zeiger nicht machbar.

genau sowas machen wir gerade inner c-vorlesung ...

[Matrix316]

Und wenn eine Funktion mehr als einen Rückgabewert haben soll gehts auch mit Zeiger...

Aber ich versuch eben möglichst so zu programmieren, dass ich ohne Zeiger auskomme. ;D

[Wuzel]

Originally posted by Matrix316
Und wenn eine Funktion mehr als einen Rückgabewert haben soll gehts auch mit Zeiger...

Aber ich versuch eben möglichst so zu programmieren, dass ich ohne Zeiger auskomme. ;D

:O ?! Ich hoffe dir ist bewusst was du da geschrieben hast ( wenn du's wirklich ernst meinst und es kein sarkasmus o.ä ist ) , eine Anwendung würd ich mir von dir mit dieser Aussage garantiert nicht programmieren lassen. ( Heap Ahoi )

[Matrix316]

Jetzt tu nicht so als ob die Welt unter geht wenn man auf Zeiger verzichten kann!!! Mann mann mann. *devil*

Ich hab ja geschrieben: Wenn es unbedingt notwendig ist, nehm ich natürlich auch Zeiger...

Was sind denn die großen Vorteile von Zeiger? Ich sehe kaum einen...

[Nagilum]

Wuzel meinte wohl eher die Rückgabe von Pointern aus Funktionsaufrufen. Die aufrufende Funktion sollte sich eigentlich nicht darum kümmern müssen den Heap wieder leerzuräumen.

[Nasenbaer]

Originally posted by Matrix316
Was sind denn die großen Vorteile von Zeiger? Ich sehe kaum einen...

Beispielsweise folgendes:

Wenn ich einer Funktion z.B. ein sehr großes Array übergeben will. Dann würde das Programm im Normalfall eine Kopie davon erstellen und diese Funktion würde auf die Kopie zugreifen. Das Erstellen dieser Kopie beansprucht aber erstens zusätzlichen Speicherbedarf und zweites kostet es je nach Größe auch Zeit.
Unter C++ gibt's zwar auch Call by References -> int Testfunc( int &Zahl) aber letztendlich ist es auch nichts anderes als -> int Testfunc( int *Zahl)

Ein anderes Beispiel wären mehrere Rückgabewerte. Wenn man also C++ nicht nutzt sondern reinen C Code hat gibt's auch Call byReference nicht.
Normalerweise kann man nur einen Wert zurückliefern. So könnte man die Rückgabewerte aber in die Parameterliste schreiben und diese Werte dann in der Funktion verändern.


void TestFunc( float Zahl, float *Halb, float *Viertel, float *Achtel)
{
*Halb = Zahl / 2;
*Viertel = Zahl / 4;
*Achtel = Zahl / 8;
}

So, diese Funktion liefert gleich 3 Werte zurück.

Verkettete Listen wären dann noch zu nennen als Möglichkeit geringe Anzahl an Datensätzen effizient zu speichern, i.e. den Riesen overhead für eine Datenbankanbindung zu vermeiden.

Mfg Nasenbaer

[Spacefrogg]

to wuzel,

warum ist es gerade bei Unix (Linux) nötig erst C zu lernen? Ich meine damit, dass ich eher Anwendungsprogrammierung betreiben will. Heißt also Fensterdesign etc., vorwiegend wohl qt oder gtk, weiß noch nicht.

Ist dabei nicht auch eher Cpp vonnöten??

µ

[Wuzel]

Originally posted by Spacefrogg
to wuzel,

warum ist es gerade bei Unix (Linux) nötig erst C zu lernen? Ich meine damit, dass ich eher Anwendungsprogrammierung betreiben will. Heißt also Fensterdesign etc., vorwiegend wohl qt oder gtk, weiß noch nicht.

Ist dabei nicht auch eher Cpp vonnöten??

µ

Ja für die Grafik an für sich schon, grad QT.
Aber um effektiv mit z.B Lin arbeiten zu können sind C Kenntnisse unabdingbar, sei's auch 'nur' um sich 'wrapper' zu C++ für System Geschichten zu bauen.
Einheitliche C++ bibis wo überall verfügbar sind gibts leider nur für KDE.
Wer also hauptsächlich mit/für KDE 'arbeitet' ohne 'Systemberührung' hat da keine Probs.
Alerdings ist dies eine sehr eingente und langweilige Art auf Lin zu progen, erst ausserhalb des C++/KDE Käfigs wirds spannend.
Zumal solche Progs wie KDE-only nich so dolle sind ( meiner Meinung nach ).

Der Satz müsste übrigens heissen -> Zeiger verwenden wos nur geht um so wenig wie möglich den stack zuzupusten und abenteuerliche Kopierkonstrukte zu vermeiden, ganz zu schweigen von der Polymorphie, unter C++ ist es schier unmöglich resourcenschonend mit Zeigersparsamkeit zu progen.
Mag sein das bei 2-3 Klassen aufm Stack nichts wildes loss ist, aber bei 200-300 ?? -> wenn's der Compilierer noch macht ( warscheins nur mit der nicht sehr schönen erhöhung der standart stack size ), läufts bestimmt wien Mofa auf der Autobahn.

[Vedek Bareil]

Originally posted by Nasenbaer
Wenn ich einer Funktion z.B. ein sehr großes Array übergeben will. Dann würde das Programm im Normalfall eine Kopie davon erstellen und diese Funktion würde auf die Kopie zugreifen. hm, also nach dem was ich gelesen habe (in T. Müller: "Einführung in C++")wird das auch dann wenn man folgendes macht:

double Ray;
...
func(Ray);
...
void func(double Ar[])
{
// mach was
}
automatisch so geregelt, daß Ar keine Kopie von Ray ist, sondern ein Pointer auf Ray. Ganz so als würde da

void func(double* Ar) stehen.

[size=1] Wenn man also C++ nicht nutzt sondern reinen C Code hat gibt's auch Call byReference nicht. sicher? Soweit ich weiß, gibt es unter C zwar den Datentyp Referenz nicht, wohl aber Call by Reference. Das nämlich benötigt den Typ Referenz nicht, sondern geht auch mit Pointern. Z.B. ist das obige Beispiel mit void func(double Ar[]) bzw. void func(double* Ar) ein Beispiel für Call by Reference.

[Tom Servo]

Originally posted by Wuzel
Ich hoffe dir ist bewusst was du da geschrieben hast ( wenn du's wirklich ernst meinst und es kein sarkasmus o.ä ist ) , eine Anwendung würd ich mir von dir mit dieser Aussage garantiert nicht programmieren lassen. ( Heap Ahoi )

Ich hab das zwar nicht geschrieben, aber ich denke er meint das Übergeben von Adressen als Parameter. So kann die Funktion dort die Rückgabewerte hinschreiben. Also das was man auch bei scanf() macht.
Wozu sollte er sonst sagen, dass Pointer mehrere Rückgabewerte ermöglichen? Die Parameter in einer solchen Funktion sind Pointer-Variablen.



Vom Spassfaktor finde ich übrigens funktionale Programmierung empfehlenswert (also Lisp und seine Nachfolger). Meiner Meinung nach auch gut geignet wenn man noch zur Schule geht, da es bei funktionaler Programmierung sehr mathematisch zugeht.

C++ sollte man m.E. nicht ohne Lehrer lernen, wenn man es nicht wirklich braucht. Die Sprache ist riesig und unterstützt mehrere Paradigmen. Recht verwirrend für Anfänger ohne Lehrer und man wird diese Sprache nie restlos beherrschen. Es gab da mal im Usenet dieses Guru-of-the-Week (http://www.gotw.ca/gotw/). Erstaunlich was man alles so falsch machen kann. Nun kann man einen falschen Ehrgeiz bekommen unbedingt diese schwierige Sprache lernen zu wollen. Aber Spass machts keinen und es ist auch nicht so, dass die Welt unbedingt noch mehr C++ oder andere Programmierer braucht. Sollte schon Spass machen und mit einfachen Sprachen lernt man dann mehr über das zu lösenden Problem weil man den Kopf frei hat.

Wer OO programmieren will kann das übrigens auch in C bzw. muss das manchmal auch in C. Also ist es nicht verkehrt wenn man OO lernt obwohl man kein C++ kann. Ich habe OO mit einem Eiffel Buch von Bertrand Meyer gelernt, aber Eiffel selber nie benutzt. C++ kann ich zwar auch, aber solange C ausreicht beschränke ich mich darauf.

[Nasenbaer]

Originally posted by Vedek Bareil
hm, also nach dem was ich gelesen habe (in T. Müller: "Einführung in C++")wird das auch dann wenn man folgendes macht:

double Ray[Size];
...
func(Ray);
...
void func(double Ar[])
{
// mach was
}
automatisch so geregelt, daß Ar keine Kopie von Ray ist, sondern ein Pointer auf Ray. Ganz so als würde da

void func(double* Ar) stehen.

Hmm das wusste ich nicht. Aber man könnte anstelle des Arrays einfach ne riesige Struktur nehmen und schon hätten die Zeiger auf wieder ihre Berechtigungen in einem solchen Anwendungsfall. :)

Originally posted by Vedek Bareil
sicher? Soweit ich weiß, gibt es unter C zwar den Datentyp Referenz nicht, wohl aber Call by Reference. Das nämlich benötigt den Typ Referenz nicht, sondern geht auch mit Pointern. Z.B. ist das obige Beispiel mit void func(double Ar[]) bzw. void func(double* Ar) ein Beispiel für Call by Reference.
Nagut wenn man das vorher auch schon so nannte, dann ist das mein Problem. Das es mit Zeigern auch geht hab ich ja auch hingeschrieben. :)

Mfg Nasenbaer

[Xmas]

Originally posted by Vedek Bareil
hm, also nach dem was ich gelesen habe (in T. Müller: "Einführung in C++")wird das auch dann wenn man folgendes macht:

double Ray[Size];
...
func(Ray);
...
void func(double Ar[])
{
// mach was
}
automatisch so geregelt, daß Ar keine Kopie von Ray ist, sondern ein Pointer auf Ray. Ganz so als würde da

void func(double* Ar) stehen.

Ja, double Ar[] und double* Ar sind funktional identisch und austauschbar. Das liegt daran dass Arrays keine echten Datentypen sind. Der Name eines Arrays ist ein Pointer, "Ray" ist in deinem Beispiel vom Typ double*.
Mehrdimensionale Felder tragen im Typ alle Dimensionen bis auf eine.

[Tom Servo]

Originally posted by Xmas

Ja, double Ar[] und double* Ar sind funktional identisch und austauschbar. Das liegt daran dass Arrays keine echten Datentypen sind. Der Name eines Arrays ist ein Pointer, "Ray" ist in deinem Beispiel vom Typ double*.
Mehrdimensionale Felder tragen im Typ alle Dimensionen bis auf eine.

Also das stimmt so generell nicht, dass der Name eines Arrays ein Pointer wäre. Denk mal an den sizeof Operator. IIRC gabs da immmer so nette Erklärungen vom zerfallen eines Array in einen Pointer wenn es im Pointer Kontext verwendet wird. hier stehts. (http://groups.google.com/groups?selm=8sq7bm%24omi%2412%40candy.pop-hannover.de&output=gplain)

Nur (?) in Funktionsparametern ist das leere name[] ohne Angabe der Array-Größe m.W. das gleiche wie ein *name.

edit:
Nochwas zum Thema Pointer, weiss nicht ob es hier jemanden hilft. Bin eigentlich auch der Meinung das man Programmieren am wenigsten in Foren oder Newsgroups lernen wird.
Ich würde empfehlen den Asterisk immer rechts an den Namen zu schreiben auch wenn es oft anders empfohlen wird z.B von Stroustrup.

In C werden Zeiger-Typen ja nicht direkt deklariert.
Es gibt keine extra Syntax für einen ptr_of double Datentyp sondern man überlegt (rekursiv?) welchen Typ eine Variable haben muss damit sich nach Anwendung der Operatoren der ganz links stehende Typ ergibt.

double *x
damit *x ein double ergibt muss x ein ptr_of double sein

int *y[10]
damit *y[0] ein int ist muss y ein Array aus ptr_of int sein (dabei beachten das der rechtsstehende Operator immer Vorrang hat, also erst [] dann *)

int *z()
damit *z() ein int ergibt muss die z Funktion einen ptr_of int zurückliefern.

Natürlich muss man den Typ nicht raten, sondern man weiss ja das ein name[10] auf jeden Fall schonmal ein Array sein muss. Und bei *name[10] weiss man das es ein Array ist welches Pointer enthält. Bei int *name[10] erfährt man dann noch, dass diese Pointer auf int zeigen.

[Wuzel]

Naja nicht vergessen,
Objekte mit new erzeugt liegen solange aufm Heap wie ichs will, das heisst ich kann überall im code wo ich bin ohne neuintialisierung der Funktionen und Variablen meines Objekts drauf zugreifen.
Würde ichs einfach nur immer intialisieren, würde an jeder Stelle im Code wo ich drauf zugreif eine neuintialisierung stattfinden.
Wenn ich ca. 150 Obkjekte hab die ich zur Laufzeit 300 mal intialisiere -> AMEN.
Ganz zu schweigen das alle Objekte aufm Stack nur Temponär sind, sprich Funktionsüberschreitende datenverwaltung adde, ich müsste alle Rückgabewerte in globale Variablen Schreiben die ich zur Laufzeit benötige ( daten serialisierung kommt auch gut, wenn ich z.B Logfunktion die ins .txt schreiben 10000x file auf , file zu, schreiben, lesen etc. etc. , da speicher ich alles in die Member's von der logfunktion, puste Sie zur Laufzeit voll, nach beendigung oder error ( Errorhandlings schreiben/abfangen ) wird erst geschrieben !Also nur ein einziges mal File auf, File zu schreiben , statt 1000 x mal ( war ein kleines beispiel ))

da liegt auch der Grund warum in der MFC z.B alles über Polymorphie und Zeiger gelöst wurde -> speeed.
Ebenfalls würde ein allocalisieren des Speichers ohne massiven Zeigereinsatz in ein Fiasko enden, ich weiss ja nie wieviel Speicher mein App grade braucht , über Objekte aufm Heap ists kein Problem da die immer oder auch nicht, je nachdem wie ichs will, im speicher liegen.
Im Alltag legt man sogar eigene Aufräum Objekte die zur Laufzeit entsprechend handeln an, um nicht irgendwo ein leak zu kriegen ( inteli Memory manager ).
Wenn man mal schaut wie z.B Runtime's von Java arbeiten und wie eine corbage Colection arbeitet, so stellt man fest das eigentlich jedes Objekt aufm heap initialisiert und dort verwaltet wird, ähnlich wies ein C/C++ proger per Hand zu Fuss regeln müsste.

[Xmas]

Originally posted by Tom Servo
Also das stimmt so generell nicht, dass der Name eines Arrays ein Pointer wäre. Denk mal an den sizeof Operator. IIRC gabs da immmer so nette Erklärungen vom zerfallen eines Array in einen Pointer wenn es im Pointer Kontext verwendet wird. hier stehts. (http://groups.google.com/groups?selm=8sq7bm%24omi%2412%40candy.pop-hannover.de&output=gplain)

Nur (?) in Funktionsparametern ist das leere name[] ohne Angabe der Array-Größe m.W. das gleiche wie ein *name.
Ja, der Arrayname ist streng genommen kein Pointer, kann aber bis auf das sizeof praktisch immer als (const) Pointer verwendet werden. Andersrum ist der Array-Operator [] auch auf Pointer anwendbar. Die leeren eckigen Klammern sind nur bei Funktionsparametern oder bei einem per {} initialisierten Array zulässig. Es hätte heißen müssen:
Ja, double Ar[] und double* Ar sind hier funktional identisch und austauschbar