BeBur schrieb:
Im Regelfall sollte man die Funktionen aus std verwenden. Die interagieren konsistent mit anderen Teilen von std, die Wahrscheinlichkeit von Bugs ist um ein vielfaches geringer und die Laufzeit ist für den alllgemeinen Fall üblicherweise optimal oder nahezu optimal. Mal ganz davon abgesehen, dass es sehr ineffizient ist, solche allgemeinen Funktionalitäten zu implementieren, die schon in hoher Qualität existieren.
So ist es. Wenn immer die Standardbibliothek bereits eine Funktionalität bereitstellt, sollte praktisch immer diese genutzt werden. Denn diese ist höchstwahrscheinlich bug-frei, effizient, allgemein bekannt (andere kennen sich im Code sofort aus, und man selber nach 6 Monaten Pause ebenfalls !) und noch dazu gratis (sensu: Arbeitsstunden-frei). Win-win-win-win. Die Chance, was besseres selber zu basteln, ist entsprechend gering und eher nur in ganz konkreten Spezialfällen zu finden.
Und über das letzte bißchen an Performancen sollte man sich nur Gedanken machen nachdem gezieltes Profiling für einen ganz konkreten Anwendungsfall tatsächlich ein nennenswertes Problem identifiziert hat. Und das ist selten der Fall (meine Erfahrung: Das Performance-Thema wird überbewertet, und selbst wenn die Performance eine Rolle spielt, liegt man sowieso falsch wo das wirkliche Bottleneck herkommt).
kali-hi schrieb:
int main() {
const auto in = {1, 2, 3, 4, 5, 6};
print("in", in);
std::vector<int> out;
const int max = in.size() + 2;
auto gen = std::default_random_engine{std::random_device{}()};
for (int n{}; n != max; ++n)
{
out.clear();
std::ranges::sample(in, std::back_inserter(out), n, gen);
std::cout << "n = " << n;
print(", out", out);
}
}[/CODE]
Wenn dir Performance so wichtig ist, dann setze dich mal mit den grundlegenden Eigenschaften der Standard-Container (bzw. der Standardbibliothek generell) auseinander. Wie schon in einem Vorpost von mir erwähnt haben die Container alle ihre jeweiligen Eigenschaften bzw. Stärken und Schwächen, und damit auch unterschiedliche "ideale" Einsatzzwecke. Den eierlegenden Wollmilchsau-Container gibt es nicht.
In Scott Meyers Buch "Effective STL" ist das z.B. gut aufgearbeitet (stammt aus 2008; als komplett veraltet würde ich es aber nicht auffassen, denn an den Prinzipien der Container hat sich nix geändert; vermutlich findet man auch was gutes aktuelleres. Und wenn ich dieses Buch erwähne ist hoffentlich auch die von
@kali-hi vor ein paar Tagen gestellte Frage beantwortet, ob ich für meine Antworten bzw. Wissen hier ChatGPT heranziehe ...).
EDIT: gilt selbstverständlich nicht nur für die Container, sondern für alle Aspekte der Standardbibliothek.
Zum konkreten Anwendungsfalls: Ein std::vector ist besonders effizient wenn Elemente nur am Ende eingefügt (oder entfernt) werden (was hier im Code mit dem std::back_inserter der Fall ist)
und weiters nochmals deutlich effizienter nutzbar wenn seine finale Größe bereits zum Zeitpunkt der Erstellung bekannt ist. Denn dann setzt man diese Größe explizit via std::vector::reserve() bevor noch Elemente hineingeschrieben werden (was also im obigen Code ergänzt werden sollte, gleich nach dem Constructor): denn dann muss der Vektor im Zuge seines Wachsens kein neues memory alloziieren und die enthaltenen Elemente vom alten memory ins neue rüberkopieren. Wird v.a. bei entsprechend großen Vektor-sizes und teuren Kopier-Operationen der Elemente eine tragende Rolle spielen, und maximal memory-efficient ist das ganze auch noch.
Fun fact: Scott Meyers empfiehlt, standardmäßig std::deque zu verwenden sofern der genaue Einsatzzweck des Containers nicht näher bekannt ist (wo und wie oft Elemente hinzugefügt/entfernt werden, finale Größe, Kosten der Kopieroperation der Elemente, etc.; siehe das oben genannte Buch zum Nachlesen der Details). Ein in der Praxis oft unterschätzter bzw. wenig genutzter Container, der noch am ehesten die positiven und negativen Eigenschafter der (sequentiellen) Container ausbalanciert, quasi der Mittelweg.
(Im hiesigen Bsp. ist aber std::vector besser).
Sorry
