Super dargestellt und echt verständlich erklärt. Für Leute, die in C++ schon fortgeschrittener sind gibt es auf RUclips kaum gute Tutorials. Deine hingegen sind echt informativ und nachvollziehbar. Mach weiter so ;)
Ich hätte nochmal eine ähnliche Frage wie Pixel Killer. Nähmlich wundere ich mich gerade, warum du das kaufmännische UND (&) bei deinen Funktionsnamen verwendest. Bei Variablen verstehe ich es, aber warum beim Funktionsnamen? Also hier zum Beispiel: Farbe const &getFarbe() const
Titus Begründung ist analog zu dem const & bei der Parameterübergabe. Diese Art und Weise vermeidet eine Kopie des Farbe-Objektes bei der Rückgabe (die sonst geschehen würde). Das ist im Normalfall eine Effizienzgeschichte (auch wenn aktuelle Compiler sowas in den meisten Fällen optimieren können), kann aber auch semantisch relevant sein (bspw. wenn Farbe einen gelöschten Copy-Konstruktor hätte).
![[C++ von { bis }] 16 - Der Deadly Diamond of Death - Das Diamantenproblem](http://i.ytimg.com/vi/yNwg44n1JlU/mqdefault.jpg)
![[C++ von { bis }] 16 - Der Deadly Diamond of Death - Das Diamantenproblem](/img/tr.png)
![C++ Polymorphism and Virtual Member Functions [6]](/img/1.gif)
Super dargestellt und echt verständlich erklärt. Für Leute, die in C++ schon fortgeschrittener sind gibt es auf RUclips kaum gute Tutorials. Deine hingegen sind echt informativ und nachvollziehbar.
Mach weiter so ;)
Ganz deiner Meinung!!
Danke für die Blumen. Das war auch der Plan: es soll ruhig im Laufe der Zeit ans Eingemachte gehen, aber hoffentlich immer nachvollziehbar bleiben.
du erklärst echt gut!
Ich hätte nochmal eine ähnliche Frage wie Pixel Killer.
Nähmlich wundere ich mich gerade, warum du das kaufmännische UND (&) bei deinen Funktionsnamen verwendest. Bei Variablen verstehe ich es, aber warum beim Funktionsnamen?
Also hier zum Beispiel:
Farbe const &getFarbe() const
Titus Begründung ist analog zu dem const & bei der Parameterübergabe. Diese Art und Weise vermeidet eine Kopie des Farbe-Objektes bei der Rückgabe (die sonst geschehen würde). Das ist im Normalfall eine Effizienzgeschichte (auch wenn aktuelle Compiler sowas in den meisten Fällen optimieren können), kann aber auch semantisch relevant sein (bspw. wenn Farbe einen gelöschten Copy-Konstruktor hätte).