Stack Template o.k.?

[...]

template<class T> class Stack
{
private:
  int groesse;
  T* top;
  T* basis;

public:
  Stack (int g)    { top = basis = new T[groesse=g]; } 
  ~Stack ()        { delete [] basis;                }
  void push (T c)  { *top++ = c;                     }
  T pop ()         { return *--top;                  }
};

Ist der Entwurf für eine Template-Klasse Stack o.k., oder gibt es da Fehler?

[rüdiger]

1. also ich finde den destructor viel zu unübersichtlich, benutz doch lieber initalisierungs listen

2. könntest du bei pop nen assert hinzufügen, ob überhaupt noch ein Objekt auf dem Stack liegt

3. solltest du std::size_t anstelle int für größen Angaben benutzen

[operator void]

Der automatisch generierte Kopierkonstruktor und Zuweisungsoperator sind falsch, bzw. du musst die korrekten schreiben. Ich glaube, ich schreibe bald mal ne Internetseite mit smart-ptr-Propaganda und poste dann nur noch Links...

[helium logged out]

und warum schlägst du dann nicht gleich std::stack vor?

[operator void]

Die vorgeschlagene Klasse hat aber andere Semantiken als std::stack, und ich bin einfach mal davon ausgegangen, dass die irgendeinen Grund haben.

[peterchen]

@...:
push und pop sollten wenigstens im Debug-Build mit einem assert gegen überlauf gesichert werden. Eine korrekte Implementation sollte natürlich eine exception werfen.

push sollte evtl. als push(T const &) deklariert werden. spart eine Kopie.

@void:

Ich glaube, ich schreibe bald mal ne Internetseite mit smart-ptr-Propaganda und poste dann nur noch Links..

Mach das!

Trotzdem sollte man natürlich einen ordentlichen CopyCTor/Assignment Operator haben, und wenn's nur ist, um ruhig zu schlafen...

[einer]

und ein T stack::peek() wäre auch nicht schlecht

[...]

danke für die Hinweise
was macht peek? push und pop reichen doch.

[Bashar]

wenn du einen prädiktiven Parser baust, musst du das obere Element des Stacks öfter inspizieren als entfernen, von daher würde sich eine top-Methode anbieten. Und völlig unzusammenhängend damit zeigt Herb Sutter in Exceptional C++, dass man eine pop-Methode, die gleichzeitig das gepoppte Element zurückgibt, nicht exceptionsicher machen kann. Achja: Der kanonische Name dafür ist top, nicht peek.

[peterchen]

Und völlig unzusammenhängend damit zeigt Herb Sutter in Exceptional C++, dass man eine pop-Methode, die gleichzeitig das gepoppte Element zurückgibt, nicht exceptionsicher machen kann

Ich bin mir nicht sicher - aber wenn ich nichts übersehen habe, "zieht" das argument hier nicht, da der Stack keine allokationen pro Operation durchführt.

Der einzige, der bei dieser pop()-implementation eine exception werfen kann, ist der Copy-CTor von T. Und in dem fall ist zwar der stack-pointer schon dekrementiert, aber der Stack noch in einem ganz brauchbaren Zustand.

[peterchen]

[lösch mich ich bin eine doppelnachricht]

[Jester]

Jo, aber der Wert liegt nicht mehr auf dem Stack und wurde auch nicht zurückgeliefert, er ist also verloren.
Also zumindest nicht die starke Garantie.

[Bashar]

Ups stimmt, die Basisgarantie scheint gegeben zu sein. Ich hab das Buch leider nicht, nur mal ein paar interessante Stellen angelesen.