Vega - Grieshaber 2018-04 Übung Freitagmittag

Fortsetzung der Übung von Donnerstagabend – Schritt 8 hier nochmals wiederholt.
(Falls in der letzten Praktikumsphase nicht abgeschlossen.)

Schritt 8:

Implementieren Sie weitere Member-Funktionen nach dem Vorbild des `std::vector`. Hier eine Liste von möglichen Kandidaten in alphabetischer Reihenfolge. Für die Detals sehen Sie sich die Beschreibung dieser Member-Funktionen in `cppreference.com` an.

Natürlich gehören zu jeder dieser Funktionen auch entsprechende Erweiterungen der Testfälle!  

• operator[]
• at
• capacity
• clear
• front
• insert
• pop_back
• reserve
• resize
• shrink_to_fit

Über die Reihenfolge, in der Sie die einzelnen Implementierungen und die zugehörigen Tests schreiben entscheiden Sie bitte selbst.

Schritt 9:

Sehen Sie sich in `cppreference.com` die Konstruktoren des `std::vector` an und entscheiden Sie welche davon auch für den `vf_vector` sinnvoll sind.

Implementieren Sie anschließend zumindest den Konstruktor, der

• genau zwei Argumente besitzt, …
• … welche wiederum Iteratoren sind …
• … die einen "von - bis"-Bereich eines anderen (Standard-) Containers …
• … mitden ülichen "asymetrschen Grenzen" angeben;
• genau ein Argument vom Typ `std::initializer_list` besitzt.

Verwenden Sie – soweit sinnvoll – die mit C++11 eingeführte Konstruktor-Delegation.

Wahlweise davor oder danach:

Denken Sie auch darüber nach, nun evtl. Copy- und Move-Constructor zu implementieren.

(Und wenn Sie gerade dabei sind: Was ist mit Copy- und Move-Assignment?)

Sie müssen die folgenden Änderungen nicht unbedingt implementieren, zumindest nicht sofort.

Schritt 10:

Demonstrieren Sie, dass eine ggf. als Typ der Elemente verwendete-Klasse (Template-Argument `T` bzw. lokal-gobale Typ-Definition `value_type`) einen argumentlosen Konstrukor benötigt (im allgemeinen Spachgebrauch auch Default-Konstruktor genannt).

Erklären Sie auch, warum das so ist!

Die Implementierung(en) welcher Member-Funktion(en) und welches Konstruktors müssten ggf. angepasst werden, um unter Verwendung von

• Placement New und
• direken Destruktor-Aufrufen

die Notwendigkeit eines Default-Konstuktors für die Klasse der Elemente zu vermeiden?

(Wäre mit diesen Änderungen dann alles getant oder fehlt evtl. noch etwas sehr Wichtiges?)

Sie müssen die folgenden Änderungen nicht unbedingt implementieren, zumindest nicht sofort.

Schritt 11:

Welche weiteren globalen Funktionen (also nicht: Member-Funktionen) erscheinen für den `vf_vector` sinnvoll?

Orientieren Sie sich auch hier wieder am `std::vector` so wie in `cppreference.com` beschrieben.

Sie müssen diese Änderungen nicht unbedingt implementieren, zumindest nicht sofort.

Schritt 12:

Wie könnte man die Argument-Übergabe an die Member-Funktion `push_back` optimieren?

Warum wäre auch eine Member-Funktion `emplace_back` analog zu des `std::vector` nützlich?

Warum sollte die Argument-Übergabe an diese Funktion mit *Perfect-Forwarding* erfolgen?