std::vector-Inhalt effizient in std::queue kopieren

[Delryn]

Hallo

Da gibt's doch sicher irgendwas aus der STL, nur die cppreference.com hilft mir da nicht weiter. Dort finde ich nur vector nach vector o.ä.

Und mit einer for-schleife Zeile für Zeile kopieren ist sicher nicht so der Hit

[CStoll]

Für die Zusammenarbeit verschiedener Container gibt es Algorithmen (und für dich auch interessant: Inserter):

vector<int> vec;
deque<int> deq;
...

copy(vec.begin(),vec.end(),back_inserter(deq));
//oder:
deq.resize(vec.size());
copy(vec.begin(),vec.end(),deq.begin());

[tntnet]

Oder auch:

vector<int> vec;
...

deque<int> deq(vec.begin(),vec.end());

Wenn der deque (oder "die deque" ) erst instantiiert wird, wenn der vector bereits gefüllt ist.

[HumeSikkins]

Hallo,
um mal Scott Meyers' zu zitieren: "Prefer range member functions to their single-element counterparts" (Effective STL - Item 5).

D.h. statt std::copy sollte man besser den Range-Ctor bzw. Range-Insert verwenden:

deq.insert(deq.end(), vec.begin(), vec.end());

[Delryn]

Geht das auch mit einer normalen queue? Copy kann nicht compiliert werden, weil die std::queue einige Methoden nicht hat, die copy braucht

[HumeSikkins]

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. 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.

In etwa so (ungetestet):

template<class Cont>
class PushInsertIterator 
	: public std::iterator<std::output_iterator_tag, typename Cont::value_type> {
public:
  typedef Cont container_type;
  typedef typename Cont::value_type value_type;
  explicit PushInsertIterator(Cont& x)
		: container_(x) {
	}
  PushInsertIterator& operator=(const value_type& val) {
		container_.push(val);
		return *this;
  }
  PushInsertIterator& operator*() {
		return *this;
  }
  PushInsertIterator& operator++() {
		return *this;
  }
  PushInsertIterator operator++(int) {
		return *this;
  }
private:
	Cont& container_;
};

template <class C>
PushInsertIterator<C> pushInserter(C& c) {
	return PushInsertIterator<C>(c);
}

Alternativ kannst du auch for_each zusammen mit einem passenden Prädikat verwenden. Ich würde in deinem Fall allerdings wohl einfach auf den Queue-Adapter verzichten und stattdessen gleich eine deque verwenden.

[camper]

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).

[Delryn]

Also ich weiß ja nicht, da kann man wohl viel mit machen, aber so wirklich intuitiv ist das ganze ja nun wirklich nicht

[HumeSikkins]

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?

[camper]

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

[we]

Ich würde sagen: Ändere dein Design.

[Delryn]

Meine Aussage war allgemein auf die Benutzung von <algorithm> bezogen.

[Dr. Prof]

Eigentlich ist es sehr intuitiv, aber man muss sich mit der STL erstmal auseinanderzusetzen um das Design zu verstehen

[CStoll]

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).

[HumeSikkins]

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

[LordJaxom]

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

[camper]

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

[HumeSikkins]

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.