std::vector-Inhalt effizient in std::queue kopieren
-
camper schrieb:
HumeSikkins schrieb:
Um den copy-mit-inserter-Ansatz benutzen zu können musst du dir einen eigenen Inserter schreiben, der nicht insert (bzw. push_back) sondern push aufruft.
oder er benutzt den back_insert_iterator, denn der benutzt auch push_back (24.4.2.2.2).
Inwieweit hilft mir das mit einer Queue, die ja nun eben gerade *keine* push_back-Methode besitzt?
-
HumeSikkins schrieb:
camper schrieb:
HumeSikkins schrieb:
Um den copy-mit-inserter-Ansatz benutzen zu können musst du dir einen eigenen Inserter schreiben, der nicht insert (bzw. push_back) sondern push aufruft.
oder er benutzt den back_insert_iterator, denn der benutzt auch push_back (24.4.2.2.2).
Inwieweit hilft mir das mit einer Queue, die ja nun eben gerade *keine* push_back-Methode besitzt?
err... gar nicht
- ist auch irgendwie unintuitiv, dass sie queue kein push_back und pop_front spendiert haben 
-
Ich würde sagen: Ändere dein Design.
-
Meine Aussage war allgemein auf die Benutzung von <algorithm> bezogen.
-
Eigentlich ist es sehr intuitiv, aber man muss sich mit der STL erstmal auseinanderzusetzen um das Design zu verstehen

-
camper schrieb:
HumeSikkins schrieb:
camper schrieb:
HumeSikkins schrieb:
Um den copy-mit-inserter-Ansatz benutzen zu können musst du dir einen eigenen Inserter schreiben, der nicht insert (bzw. push_back) sondern push aufruft.
oder er benutzt den back_insert_iterator, denn der benutzt auch push_back (24.4.2.2.2).
Inwieweit hilft mir das mit einer Queue, die ja nun eben gerade *keine* push_back-Methode besitzt?
err... gar nicht
- ist auch irgendwie unintuitiv, dass sie queue kein push_back und pop_front spendiert haben 
Eine Queue ist ja auch kein Container im STL-Sinn, sondern ein Container-Adapter (das stellt eine FIFO-Warteschlange dar).
-
CStoll schrieb:
camper schrieb:
HumeSikkins schrieb:
camper schrieb:
HumeSikkins schrieb:
Um den copy-mit-inserter-Ansatz benutzen zu können musst du dir einen eigenen Inserter schreiben, der nicht insert (bzw. push_back) sondern push aufruft.
oder er benutzt den back_insert_iterator, denn der benutzt auch push_back (24.4.2.2.2).
Inwieweit hilft mir das mit einer Queue, die ja nun eben gerade *keine* push_back-Methode besitzt?
err... gar nicht
- ist auch irgendwie unintuitiv, dass sie queue kein push_back und pop_front spendiert haben 
Eine Queue ist ja auch kein Container im STL-Sinn, sondern ein Container-Adapter (das stellt eine FIFO-Warteschlange dar).
Fünf Stunden zuvor:
HumeSikkins schrieb:
Delryn schrieb:
Geht das auch mit einer normalen queue?
Eine queue ist kein Container sondern lediglich ein Container-Adapter mit dem Nachteil, dass sie nicht über das Standard-Interface eines Containers verfügt.
Irgendwie ist dieser Thread eigenartig

-
Im Normalfall würde ich Dir Recht geben HumeSikkins, aber heute ist dieser Thread doch echt noch harmlos

-
der titel dreht sich um queue und dann kommt in den ersten posts nur deque, und ich überles nat. glatt den post von Hume (was nat. unklug ist, denn Hume würde sowas nicht vorschlagen, wenn es nicht notwendig wäre). egal. nur um noch mal kurz drauf zurückzukommen: ich habe nie verstanden was stack und queue in der standardbibliothek verloren haben - da ist kein gewinn an funktionalität oder bequemlichkeit. des standard interface für container wird ohne not aufgegeben. selbst basic_string leistet sich ja size und data memberfunktionen, obwohl es ebenfalls kein container ist. zugegeben, basic_string ist sowieso hoffnungslos überfrachtet - da kommt es dann evtl. nicht so drauf an. ich kann mir einfach nicht vorstellen, dass diese adapter irgendwo ernsthaft eingesetzt werden - statt dessen haben sie hash_map aus der STL herausamputiert und haben jetzt den ärger, das ding mit einem völlig ungewohnten namen bennen zu müssen.
egal, das wollte ich nur mal loswerden

-
camper schrieb:
ich habe nie verstanden was stack und queue in der standardbibliothek verloren haben - da ist kein gewinn an funktionalität oder bequemlichkeit.
Sehe ich genauso. In meinen Augen ein klassisches Beispiel für ein zu minimales Interface. Wirkt auf dem Papier zwar toll, in der realen Welt aber völlig unbrauchbar, da unhantlich zu bedienen.