STL

[unskilled]

das der stack hier über eine deque implementiert wird, würde ich raten - macht aber imho nicht all zu viel sinn^^

bb

[blurry33]

das ganze als list zu implementieren wär das nicht sinnvoller ?

Jetzt noch die Frage über den Nutzen der Container. Sollte man z.B. den
list Container verwenden oder sich selbst eine Liste schreiben.
Haben die Container der STL irgendwelche Nachteile ? Werden sie von
Software Firmen verwendet ?

[Nanyuki]

Nö, der Speicher- und Zeitoverhead dürfte bei list größer sein.
Zu den anderen Fragen: ja/nein/nein/ja (jeweils gerundete Antworten).
Gegenfrage: was macht dich glauben, eine eigene Implementation könnte wesentliche Vorteile bieten? Auf dieser Basis könnte man sinnvollere Diskussionen führen.

[.filmor]

Verwende immer die Standard-Container, im Zweifel std::vector. Viele Firmen verwenden diese nicht, weil ihre Programme (oder Programmierer) schön urig sind und es die Standardbibliothek "erst" seit ~12 Jahren gibt, aber davon brauchst du dich nicht beeinflussen lassen.

std::list würde ich in den allermeisten Fällen eh die Finger von lassen, fast immer ist ein normaler std::vector schneller.

Die Allokatoren würde ich in Ruhe lassen, die sind eine ziemliche Fehlkonstruktion.

[blurry33]

in der Firma wo ich Praktikum gemacht habe, die haben alle Funktionen
selber geschrieben. Aber ich könnte mir vorstellen , dass man z.b.
irgendwelche Funktionen noch dazu haben will.

Wie ist es z.B. beim Stack . mit stack.pop() kann ich das oberste
Element zwar runterholen, aber mit cout<<stack.pop() funktioniert das nicht.
Wie kann ich meinen stack dann ausgeben ? außer empty,size,top,push,pop
gibt es keine funktionen

[blurry33]

Sorry. Es geht wohl mit stack.top();

[blurry333]

aber z.B. könnte man die Mitte oder das unterste Element ausgeben wollen.
Diese Funktionalität fehlt beim STL stack

[unskilled]

blurry333 schrieb:

aber z.B. könnte man die Mitte oder das unterste Element ausgeben wollen.
Diese Funktionalität fehlt beim STL stack

nein, die fehlt nicht - deshalb ist es ein stack... : D

[brotbernd]

Ein stack ist ein stack. Da packt man oben was drauf und nimmt es oben wieder runter. Der stack ist wie queue eigentlich gar kein richtiger Container, sondern ein Wrapper. Das gleiche kannst du auch mit deque machen. Du machst blos mit dem Wort stack deutlich, dass es um einen Stapel geht, von dem Du niemals was von unten rausziehst.
Wenn Du oben und unten Elemente rein&raus nehnmen willst, ist std::deque das richtige. Für Elemente in der Mitte list.

[Nexus]

unskilled schrieb:

das der stack hier über eine deque implementiert wird, würde ich raten - macht aber imho nicht all zu viel sinn^^

Wieso nicht? Ich nehme an, die Standardmenschen haben sich schon was dabei überlegt und sind zum Schluss gekommen, dass in den meisten Fällen eine std::deque schneller ist, weil sie gleich mehrfach allokieren und deallokieren kann. Ausserdem ist der Overhead durch Verkettungszeiger geringer.

.filmor schrieb:

std::list würde ich in den allermeisten Fällen eh die Finger von lassen, fast immer ist ein normaler std::vector schneller.

std::list finde ich vor allem sehr praktisch, wenn Zeiger, Referenzen und Iteratoren auf Elemente gültig bleiben sollen. Sie kann sich auch bewähren, weil man schnell Elemente in der Mitte (z.B. beim Durchiterieren) löschen kann. Allerdings sollte man im Normalfall davon absehen, std::list für relativ kleine Objekte zu verwenden.

[unskilled]

vorteile sind wohl, dass nicht umkopiert werden muss und speicher freigegeben werden kann, der nicht mehr verwendet wird - ich würd vrmtl trotzdem den vector bevorzugen, da er doch wieder schneller ist - und wenn der zu speichernde typ nicht unendlich groß ist, machts auch nichts aus, wenn man die paar byte die ganze zeit allokiert lässt...

bb

[Nexus]

Ich verstehe deinen Post nicht. Ich habe ja bereits Vorteile erwähnt, wieso also "Vorteile sind wohl..."? Und warum "ich würd vrmtl trotzdem den vector bevorzugen, da er doch wieder schneller ist"? Sowas kannst du doch nicht pauschal sagen.

[unskilled]

also allokationen (und deallokationen) wird die deque mind. genau so viele haben, wie der vector
bei der vector-version muss nur umkopiert werden, wenn man davor das reserve vergessen hat bzw. nicht machen konnte, weil man sich nicht sicher sein konnte, wie groß das ganze sein wird...
jz wieder: wenn das objekt nicht unendlich groß ist, kann man halt rel. viel reservieren ohne, dass es jmd stört...
wenn das nicht möglich ist, sollte man halt doch die deque nehmen^^

bb

[Nexus]

Ah okay, ich dachte, du würdest dich auf std::list (meinen ersten Abschnitt) beziehen. Aber du meinst ja std::stack .

Ich habe vorher eher std::deque im Gegensatz zu einer std::list gemeint. An std::vector habe ich hier gar nicht gedacht (wohl, weil er zu std::queue nicht kompatibel ist und ich die Adapter aufgrund fehlender Flexibilität sehr selten verwende).

Ich kann mir vorstellen, dass ein std::stack fähig sein soll, schnell die Grösse zu ändern, ohne viel Speicher zu verschwenden. Vielleicht liegt einem auch etwas daran, dass alle Operationen ungefähr gleich lange dauern (beim std::vector geht wohl viel mehr Zeit verloren, wenn eine Reallokation bei grossen oder vielen Objekten fällig ist). Andererseits kann es gerade durch Grössenschwankungen sinnvoll sein, etwas Speicher vorrätig zu haben.

Aber das sind eigentlich nur Spekulationen. Vielleicht wurde auch eine Münze geworfen.