Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
const std::vector hat allerdings eben auch einen ganz anderen Nutzen als const std::unique_ptr&. Letzterer ist komplett überflüssig. Ein const Raw* ist wesentlich besser geeignet. Es suggeriert bei flüchtigem Blick auch keine Übertragung der Ownership. Ich hoffe "es sieht modern aus" ist nicht das einzige Argument, welches du für so ein merkwürdiges Konstrukt (const unique&) anführen kannst.Klar sind sie hübscher, aber dafür hat man auch moderneren Code. Man benutzt heutzutage schließlich auch void bar(const std::vector<Foo>& foobar) statt void bar(Foo foobar[])
4) Raw-Pointer sind schon irgendwie hübscher als const-Referenzen auf Unique-Pointer.
4) Raw-Pointer sind schon irgendwie hübscher als const-Referenzen auf Unique-Pointer.
Klar sind sie hübscher, aber dafür hat man auch moderneren Code. Man benutzt heutzutage schließlich auch void bar(const std::vector<Foo>& foobar) statt void bar(Foo foobar[])
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (01.04.2015, 21:27)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BlueCobold« (01.04.2015, 21:35)
4) Raw-Pointer sind schon irgendwie hübscher als const-Referenzen auf Unique-Pointer.
Klar sind sie hübscher, aber dafür hat man auch moderneren Code. Man benutzt heutzutage schließlich auch void bar(const std::vector<Foo>& foobar) statt void bar(Foo foobar[])
Imo ist die Variante mit dem Array zu bevorzugen, da sie für alle möglichen Arten von Arrays (inklusive std::vector) funktioniert, nicht nur für std::vector...
C-/C++-Quelltext |
|
1 2 3 4 |
int* i = new int; double* d = i; delete d; |
Was passiert dann?
C-/C++-Quelltext |
|
1 2 3 4 |
struct Bla { std::vector<int> v; } int* i = new int; auto bla = reinterpret_cast<Bla*> (i); delete bla; |
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Iteratoren sind aber eventuell gar nicht das, was der Empfänger braucht. Wenn er wahlfreien Zugriff benötigt, sieht es mit einem Iterator sehr schlecht aus. Ein RandomAccessIterator könnte wiederum gehen.Wenn man verschiedene Datenstrukturen unterstützen will darf man wohl nur Iteratoren annehmen.
Im Gegensatz zu std::vector wird bei einer List oder Deque garantiert, dass die bereits darin enthaltenen Elemente ihre Adresse immer behalten, egal ob Du Elemente entfernst oder hinzufügst. Das kann schon manchmal sehr wichtig sein. Außerdem wissen wir ja, dass Lösch- oder Einfüge-Operationen auf einem Vektor potentiell sehr teuer sein können. Muss der Empfänger z.B. plötzlich immer vorn irgendwas anfügen statt wie bisher hinten... nun ja. Es kann durchaus vorkommen, dass sich das ändert.Warum sollte man auf std::list oder std::deque umstellen wollen?
Die Container haben sich bei mir in der Praxis noch nie als vorteilhaft herausgestellt.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Spiele Programmierer« (02.04.2015, 11:26)
Werbeanzeige