Wie lange zum Einarbeiten in C++

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.

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)

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

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.

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

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.

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.