Hallo, wie lange benötigt man bei vorhandenem C-Verständnis sowie 3-4h / Tag Zeit in etwa, um c++ zu verstehen und in Verbindung mit verschiedenen Libs einsetzen zu können? Einarbeitungszeit in die jeweilige Lib soll jetzt mal nicht berücksichtigt werden ...
Wenn Du C wirklich gut beherrschst, dann sollte die Einarbeitung in C++ so ziemlich genau solange dauern, wie Du zum lesen des jeweiligen Tutorials und ggf. für die Aufgaben dort benötigst. Bei 3-4h sollten 2-3 Tage für die Grundlagen wie Klassen, Vererbung, Templates und Exceptions reichen. Für die Details bracht man dann noch 3-6 Wochen, wenn man sich damit auch richtig beschäftigt. MfG Mark
Mark P. wrote: > Wenn Du C wirklich gut beherrschst, dann sollte die Einarbeitung in > C++ so ziemlich genau solange dauern, wie Du zum lesen des jeweiligen > Tutorials und ggf. für die Aufgaben dort benötigst. Bei 3-4h sollten 2-3 > Tage für die Grundlagen wie Klassen, Vererbung, Templates und Exceptions > reichen. Das sind dann aber auch wirklich nur die gröbsten Grundlagen. Die Zeit kommt mir ein wenig kurz vor. > Für die Details bracht man dann noch 3-6 Wochen, wenn man sich > damit auch richtig beschäftigt. Und bis man die gedankliche Umstellung in eine objektorientierte Welt vollzogen und verinnerlicht hat, können auch schon mal Monate vergehen. Da ist der Funktionsansatz, wie er in C praktiziert wird, eher ein Ballast, den man erst loswerden muss.
Ich hab in einem halben Jahr an der FH eine Prüfung in C++ welches Buch würdet ihr mir da empfehlen.
Hallo! @Timo: Buch "The C++ Programming Language" von B. Stroustrup (ich hoffe, das war richtig geschrieben...) @Alex: Kannst Du objektorientiert denken? Dann ist das in ein paar Tagen machbar + einige Wochen für die Libs. Ohne objektorientiertes Denken - einige Wochen für die Grundlagen + einige Wochen für die Libs. Grüße, TommyS
Timo wrote: > Ich hab in einem halben Jahr an der FH eine Prüfung in C++ Ah. ok. Dachte du wolltest wissen, wenn du dich heute als C++ Programmierer bewirbst, wie lang du deinen zukünftigen Arbeitgeber vertrösten sollst. Für Prüfungen reicht meist deutlich weniger Praxis. Da sind dann die von Mark genannten Zeiten realistisch. > welches Buch würdet ihr mir da empfehlen. Noch eine Stimme für Stroustrup. Vor allen Dingen deshalb, weil er nicht mit dem Quatsch anfängt, dir erst mal C beibringen zu wollen um dann irgendwann mittendrinn die Kurve nach C++ zu kratzen. Du hast eine std::string Klasse, also benutze sie auch. Von Anfang an. C-style-Arrays und alle Probleme die damit zusammenhängen kommen viiiieeeel später, wenn überhaupt. (Nur um mal ein Beispiel herauszugreifen, dass man in C++ völlig anders angeht)
Ich bräuchte halt ein Buch das sehr verspielt mit Zeigern und Referenzen umgeht, die String Bib häufig benutzt und sehr viel mit Interfaces und Vererbung verspielt umgeht. Unser Prof liebt solche Zeiger auf Zeiger spielchen.
Timo wrote: > Ich bräuchte halt ein Buch das sehr verspielt mit Zeigern und Referenzen > umgeht, Referenzen ja, Zeiger: eher nein. Ausser für polymorphe Dinge braucht man die in C++ deutlich weniger als in C. > die String Bib häufig benutzt und sehr viel mit Interfaces und > Vererbung verspielt umgeht. > Unser Prof liebt solche Zeiger auf Zeiger spielchen. Vielleicht sollte dein Prof auch mal einen C++ Kurs machen? (Sags ihm aber nicht. Die meisten Lehrenden auf der FH sind da sehr eigen, wenn man ihre Kompetenz anzweifelt. Auch wenn die, objektiv gesehen, nicht allzu gross ist. Da kann man sich schnell ein Eigentor schiessen) Aber: Das Zeiger auf Zeiger Spielchen funktioniert in C++ auch nicht anders als in C. Wenn du also in C fit bist, ist dieser Teil in C++ kein wirkliches Problem. Aber wahrscheinlich gehts da eh mehr um den Aufbau von wilden Datenstrukturen, die dynamisch allokiert werden. Und wie gesagt: Das löst man in C++ am besten mit std::vector, std::list, std::map und Konsorten und macht sich nicht selbst die Finger mit schnöder Speicherallokierung schmutzig. Aber wenns denn sein muss: Papier und Bleistift nehmen und die Datenstruktur mitzeichnen. Ist unabhängig von C oder C++
Timo wrote:
> Bist du ein professioneller Programmierer?
Ja.
Seit 20 Jahren
Objektorientiert denken: jein Ich kenne den Ansatz, von wegen Objekte mit Eigenschaften und Funktionen, mehrere Instanzen eine Objekts, Vererbung etc. Aber so richtig flüssig in den Gedankengang will es noch nicht rein ...
Zur Verwendung der STL gibt es verschiedene Meinungen, um das mal kurz zu fassen. Aber wenn's um eine Pruefung geht, zaehlt das, was der Prof. hoeren will - also am Besten sein Lieblingsbuch nehmen. Im Zweifelsfall duerfte Stroustrup schon passen - fuer die Pruefung...
Andere Frage noch: ich überlege mich privat für C++ zu entscheiden, um die teils sehr mächstigen Bibliotheken nutzen zu können. Java werde ich aber auch in etwa einem halben Jahr in den Grundzügen erlernen müssen. Hilft das Verständniss des Aufbaus von C++-Programmen beim erlernen von Java ?
Alex wrote: > Objektorientiert denken: jein > > Ich kenne den Ansatz, von wegen Objekte mit Eigenschaften und > Funktionen, mehrere Instanzen eine Objekts, Vererbung etc. > > Aber so richtig flüssig in den Gedankengang will es noch nicht rein ... Das dauert seine Zeit. Nicht ungeduldig werden. Ich war 8 Jahre lang mit Fortran und C industriell unterwegs. Der Umstieg in die OOP Denkweise hat (mit allen Konsequenzen) bei mir so 2 1/2 bis 3 Jahre gedauert, würde ich mal sagen. Klar hab ich C++ 'on the job' gelernt und meine ersten C++ Sachen nach wenigen Tagen geschrieben. Aber das war halt am Anfang mehr ein 'besseres C' als 'objektorientiertes C++'. Die Haupthürde ist ja nicht die Sprache an sich, sondern der andere Denkansatz mit allen Konsequenzen. Die Sprachmittel die dir C++ zur Verfügung stellt, hast du in wenigen Tagen drauf. Das ist nicht das Problem. Aber Dazu kommen dann eine Menge Idiome und wie man sie in einer OOP Welt realisiert.
Erfahrung hilft immer... aber wenn du gut in einer Sprache programmieren willst, musst du dich auf die Sprache einstellen. Wer Java programmiert, wie er in C++ programmiert, produziert sicher funktionierenden Code - aber er produziert mit Sicherheit nicht die besten Loesungen. C++ als Vorbereitung fuer Java zu betrachten, ist wohl weniger sinnvoll.
Ich hab mit folgendem Buch C++ gelernt (parallel zur Vorlesung): Ulla Kirch-Prinz, Peter Prinz C++ - Lernen und professionell anwenden Ich find das Buch super, kannst dir ja mal anschaun ob das was für dich ist. Zum Thema Java: Wenn du C++ kannst, ist Java sehr einfach zu erlernen, die paar Unterschiede die es gibt, kann man locker in nem Semester verstehn. Also es bringt schon was vorher mal C++ gelernt zu haben.
Alex wrote: > Andere Frage noch: ich überlege mich privat für C++ zu entscheiden, um > die teils sehr mächstigen Bibliotheken nutzen zu können. Java werde ich > aber auch in etwa einem halben Jahr in den Grundzügen erlernen müssen. > Hilft das Verständniss des Aufbaus von C++-Programmen beim erlernen von > Java ? Jein, grundlegende Sachen wie Kapselung, einfache Vererbung etc. ja. Bei Sachen wie Template-Metaprogrammierung oder STL (oder als Zitate von Stepanov "STL is not object oriented...I find OOP methodologically wrong."(1)), nein. (1) http://www.stlport.org/resources/StepanovUSA.html > Zum Thema Java: Wenn du C++ kannst, ist Java sehr einfach zu erlernen, > die paar Unterschiede die es gibt, kann man locker in nem Semester > verstehn. Also es bringt schon was vorher mal C++ gelernt zu haben. Für Basis-C++ -> Java mag das stimmen...
Ich kann Karl-Heinz' Aussage nur beipflichten. Selbst nach 15 Jahren C++ lerne ich immer noch Sachen hinzu, wie man Dinge einfacher und besser machen kann. Wenn die Grundlagen der OO und C++ "drin" sind, kann ich noch sehr empfehlen: Scott Meyers: "Effektive C++" (hier unbedingt auf die neueste Auflage gehen, da sich sehr viel geändert hat) Scott Meyers: "More Effektive C++" Nicolaus M. Josuttis: "The C++ Standard Library" - Brauche ich immer wieder mal zum Nachschlagen Auch wenn's Java ist: Joshua Bloch: "Effective Java", die meisten Items kann man auch in C++ anwenden.
Ingo Elsen wrote: > Selbst nach 15 Jahren C++ lerne ich immer noch Sachen hinzu, wie man > Dinge einfacher und besser machen kann. Yep. Ist ein ständiges Lernen. Ich bin jetzt schon fast 10 Jahre auf der Suche nach einem vernünftig implementierbaren 'multiple virtual dispatch' (*) und habe wenig Hoffnung, dieses Problem in C++ bis an mein Lebensende zu meiner Zufriedenheit lösen zu können (klingt theatralischer als es ist: C++ ist dafür einfach nicht mächtig genug) > Scott Meyers: "Effektive C++" (hier unbedingt auf die neueste Auflage > gehen, da sich sehr viel geändert hat) > Scott Meyers: "More Effektive C++" Yep. Die sind für einen Profi meiner Meinung nach ein absolutes Muss. > Nicolaus M. Josuttis: "The C++ Standard Library" - Brauche ich immer > wieder mal zum Nachschlagen Auch ein Klassiker der nicht fehlen darf. (*) ein 'multiple virtual dispatch' ist ein virtueller Funktionsaufruf, der über 2 oder mehr polymorphe Argumente geführt wird. Ein Beispiel wäre zb. die Berechnung des Schnittpunkts 2-er geometrischer Primitive A und B. Welche Schnittpunktsfunktion tatsächlich aufgerufen wird, hängt vom konkreten Datentyp (also Linie, Kreis, Polygon etc) von sowohl A als auch B ab. Ich kenn dafür nur 2 Lösungen * Die Schnittpunksfunktion ist Member-Funktion. Das führt dann aber unweigerlich darauf hinaus, dass die Basisklasse wissen muss, welche Klassen von ihr abgeleitet wurden -> nicht schön * Die Schnittpunktsfunktion ist keine Member-Funktion Dann braucht man ein Array welches alle Datentypkombinationen mit jeweils einer Funktion verknüpft. Zum Funktionsaufruf durchsucht man das Array nach der gegebenen Datentypkombination, kriegt einen Funktionspointer und rüft über diesen die Schnittfunktion auf. Das Problem: Wenn man nur generische Pointer hat, muss man erst mal über die RTTI den richtigen Objekttyp bestimmen, zurechtcasten und kann erst dann auf die Suche gehen -> auch nicht schön Und ja, es gibt dafür Lösungen. Smalltalk macht sowas aus dem Stand :-)
Dritte Methode, die mir einfällt (ist aber nach meinem Geschmack auch Holzhammer): Eplizit spezialisierte Templates in der Art eines template <typename A, T> class Intersector; mit jeweils ausformulierten Kombinationen. Wenn man dann die Konstruktoren der A, T noch explicit macht, kommt man m.E. ohne RTTI, weil ja vorher festgelegt, aus. Wie löst das denn Smalltalk?
Ingo Elsen wrote: > Dritte Methode, die mir einfällt (ist aber nach meinem Geschmack auch > Holzhammer):´ Seit einigen Jahren schwimm ich auf der RTTI-Tabelle-Funktionspointer Schiene. Ist für mich die wartbarste Lösung. Die Methode mit dem 'umdrehen des virtuellen Aufrufs, ala (Skizze) virtual Line::Intersect( Prim* a ) { a->Intersect( this ); } virtual Line::Intersect( Line* line ) { .. } virtual Line::Intersect( Circle* circ ) { .. } (und dasselbe nochmal für Circle), hat sich bei mir nicht bewährt. Zum einen muss die Basisklasse wissen, dass es Line, Circle etc. gibt, zum anderen artet das bei mehreren Klassen in ein Wartungsdesaster aus, wenn mal eine Klasse dazukommt. 'Plug-Play' fähig ist das nicht. > Wie löst das denn Smalltalk? soviel ich weiss, wird der virtuelle Aufruf erst zur Laufzeit vollständig aufgelöst, aber anders als in C++ werden auch die Argumentdatentypen berücksichtigt. In C++ werden ja die Argumentdatenypen bereits zur Compilezeit fixiert und daraus abegleitet welche Funktion aufgerufen werden muss. In Smalltalk wird auch die aufzurufende Funktion erst zur Laufzeit gesucht. C++ fehlt das 'dynamic binding', wie es in Sprachen wie Smalltalk oder auch Lisp vorhanden ist.
Karl heinz Buchegger wrote: >> Wie löst das denn Smalltalk? > > soviel ich weiss, wird der virtuelle Aufruf erst zur Laufzeit > vollständig aufgelöst, Ja. > aber anders als in C++ werden auch die > Argumentdatentypen berücksichtigt. Nein. Allein schon deshalb nicht, weil Smalltalk in diesem Sinn garkeine Datentypen kennt ;-). Deshalb entfällt auch der ganze Kladderadatsch um Templates, denn Methoden werden immer ohne Definition der Datentypen formuliert. Der Nachteil davon sind die Laufzeitfehler, wenn beispielsweise ein String-Objekt nicht versteht, was eine Multiplikation ist.
A. K. wrote: >> aber anders als in C++ werden auch die >> Argumentdatentypen berücksichtigt. > > Nein. Allein schon deshalb nicht, weil Smalltalk in diesem Sinn garkeine > Datentypen kennt ;-). Ah ok. Mein halber Nachmittag Smalltalk spielen ist schon seeeehr lange her. > Deshalb entfällt auch der ganze Kladderadatsch um Templates, denn > Methoden werden immer ohne Definition der Datentypen formuliert. Der > Nachteil davon sind die Laufzeitfehler, wenn beispielsweise ein > String-Objekt nicht versteht, was eine Multiplikation ist. Wo viel Licht ist, ist auch viel Schatten. Das ist dann die Kehrseite der Medaille.
Ich hatte mir das so wie unten schnell hingetippt vorgestellt. Vorteil:
Der Compiler prüft, ob die Intersection möglich ist und man muss nur an
einer Stelle die Intersection programmieren.
class Line;
class Circle;
class Rectangle;
class Point;
template typename<A, T> class Intersector
{
public:
vector<Point> intersect(A obj1, T obj2)
{
#error "NOT IMPLEMENTED"
}
}
// Hier sind jetzt die Spezialisierungen
template <> class Intersector <Line, Circle>
{
public:
vector<Point> intersect(Line obj1, Circle obj2);
}
template <> Intersector<Line, Circle>::intersect(Line obj1, Circle obj2)
{
// do something
}
Ingo Elsen wrote: > Ich hatte mir das so wie unten schnell hingetippt vorgestellt. Vorteil: > Der Compiler prüft, ob die Intersection möglich ist und man muss nur an > einer Stelle die Intersection programmieren. Äh. nein Das ganze muss polymorph funktionieren!
1 | class Geo |
2 | {
|
3 | ...
|
4 | };
|
5 | |
6 | class Line : public Geo {}; |
7 | class Circle : public Geo {}; |
8 | |
9 | ...
|
10 | |
11 | std::vector< Geo* > selectedPrimitives; |
12 | |
13 | Intersect( selectedPrimitives[0], selectedPrimitives[1] ); |
Zur Compilezeit weisst du nicht, welche Primitive das wirklich sind. Wenn ich das wüsste, brauch ich den Aufwand nicht, sondern ruf gleich die korrekte Schnittfunktion dafür auf. Bonuspunkt: Das ganze soll insofern erweiterbar sein, dass über eine DLL ein neues Geometrieobjekt eingebracht werden kann, welches sich in das System integriert und seine eigenen Schnittroutinen mitbringt, die dann auch aufgerufen werden, wenn selectedPrimitiv[0 oder 1] von diesem Datentyp ist. In diesem Fall kann der Compiler überhaupt nicht wissen, dass es diese Klasse überhaupt gibt, wenn er mit Intersect arbeiten soll.
Aha, das habe ich falsch verstanden. Jetzt ist's klar und mir fällt keine Lösung ein ;-) Erst mal denken...
1 | Buch "The C++ Programming Language" von B. Stroustrup (ich hoffe, das |
2 | war richtig geschrieben...)) |
Kann jemand was zur deutschen übsetzung sagen? Ist sie so schlecht wie ich vermute?? und was haltet ihr von Ulla Kirch-Prinz, Peter Prinz C++ - Lernen und professionell anwenden kennt ihr das?
Ich finde den Stroustroup schon auf Englisch nicht so toll um C++ zu lernen. Der C++ Primer von Lipman ist m.E. besser. Das Buch von den Prinzen kenne ich nicht.
Leute lernt Assembler:) Man muss zwar bisschen mehr Zeilen Tippen aber man löst jedes problem:)
Ich hatte mal einen Kurs, mit Lehrer, 40 Stunden. Ohne Lehrer wird es wohl dreimal so lange brauchen. Das war mit Borlands Turbo C++ für DOS. Und da war die Windows-Programmierung nicht dabei. Dafür gabs nen zweiten Kurs, wieder 40 Stunden. Und heute schreibe ich C-Code, den ich mit dem C++ - Compiler übersetzt. Ohne Vererbung. Klein und verständlich. Weiterhin nicht objektorientiert. Beispiel: Für LCD-Ansteuerung habe ich 5 Unterprogramme geschrieben, und keine Klasse mit 5 Memberfunktionen. Ich werde nie mehr als eine LCD anschließen an meine ATMega32. Das reicht.
Die letzten 2 Poster sind schon wieder so Nixraffer. In welcher Kategorie steht das hier nochmal ?
Ein Assembler- oder C-Programmierer von echtem Schrot und Korn
wird C++ meiden wie ein Vampir den Knoblauch.
Vor allen Dingen wenn es um 'kleine' Controller geht.
> Die letzten 2 Poster sind schon wieder so Nixraffer.
Lass Deinen Frust woanders ab.
hmm wrote: > Ein Assembler- oder C-Programmierer von echtem Schrot und Korn > wird C++ meiden wie ein Vampir den Knoblauch. Und wundern sich dann, dass Arbeitgeber auf so richtig schrotig kernige Hacker keine Lust haben...
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.