Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Dynamischer Stack in c++

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 <
010
29.10.2003, 16:18 Uhr
(un)wissender
Niveauwart


Die STL macht das so (mit dem pop).
Man könnte aber auch das Element, welches von pop entfernt wird zurückliefern (by value), das find ich nicht verkehrt.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
29.10.2003, 16:29 Uhr
0xdeadbeef
Gott
(Operator)


Ich fände das hier am sinnvollsten:

C++:
class Stack {
public:
  Stack& push(int);
  int peek(); //gibt das oberste Element zurück
  int pop(); //gibt das oberste Element zurück und nimmt es vom Stack
};


--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 29.10.2003 um 16:30 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
29.10.2003, 16:30 Uhr
virtual
Sexiest Bit alive
(Operator)


Bei einem int ist das möglicherweise nicht tragisch, ja. Aber bei einem Template, wo dann beliebig komplexe Dinge hinter einem Element stecken können, finde ich das nicht so ganz optimal (by value return impliziert zweifachen Aufruf vom Copyconstructor).(*)
Auch rein designtechnisch finde ich sowas immer ein wenig fragwürdig: Jede Funktion sollte meiner Meinung nach eine klar Umrissene Aufgabe haben. Unter poppen verstehe ich - in diesem Zusammenhang - das
Entfernen des Elementes on top if stack. Nicht mehr und nicht weniger.


(*) --edit: wovon einer im zweifel überflüssig ist, nämlich genau dann, wenn einen das Resultat vom pop nicht interessiert
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)

Dieser Post wurde am 29.10.2003 um 16:40 Uhr von virtual editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
29.10.2003, 19:54 Uhr
(un)wissender
Niveauwart


Oder auch nicht.
Compiler sind durchaus in der Lage so was wegzuoptimieren.
Aber ansonsten ist das wohl eher eine Glaubensfrage, wobei klar definierte Funktionen immer gut sind, da gebe ich dir recht.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
30.10.2003, 00:51 Uhr
0xdeadbeef
Gott
(Operator)


Compiler werden einen Teufel tun, das wegzuoptimieren. Was ist, wenn der Konstruktor irgendwelche Sachen macht, die den globalen Kontext beeinflussen? Ein Instanzzähler, zum Beispiel. Gut, sowas kommt nicht sonderlich häufig vor, aber wenn es vorkommt, darf der Compiler es nicht einfach raushauen. Dementsprechend ist es alles andere als trivial, das rauszuoptimieren.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
30.10.2003, 06:43 Uhr
(un)wissender
Niveauwart


Nein, denn es ist ein unbenanntes Objekt entstanden!
Das darf wegoptimiert werden!
Darauf, was der Compiler mit anonymen Objekten macht, habe ich kein "Recht", d.h. er kann damit "fast" tun und lassen was er will.
Selbst benannte Objekte werden im Zuge der Returnwertoptimierung manchmal wegoptimiert, schon alleine die Returnwertoptimierung von unbenannten Objekten dürfte es aber nach deiner Theorie nicht geben.
Es gibt sie aber.
--
Wer früher stirbt ist länger tot.

Dieser Post wurde am 30.10.2003 um 06:46 Uhr von (un)wissender editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
016
30.10.2003, 06:57 Uhr
(un)wissender
Niveauwart


Habe es gerade mal getestet, einmal hat der g++ 3.3 das temp. Objekte wegoptimiert, einmal nicht.
Andere Compiler schaffen das vielleicht immer(?), keine Ahnung, habe nur den g++.
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
017
30.10.2003, 07:05 Uhr
(un)wissender
Niveauwart


Ah, Blödsinn, mein Test war schlecht, habe den Copyconstruktor nicht überladen.
Also der g++ hat immer ein temp. Objekte erstellt, das stützt nicht gerade mien Aussage.
Bin aber trotzdem noch der Meinung, das die wegoptimiert werden können.

virtual, was sagt der Standard?
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
018
30.10.2003, 07:42 Uhr
virtual
Sexiest Bit alive
(Operator)


Der Standard läßt sich nicht zu Optimierungen aus, IMHO.
Also ich denke mal einfach, daß es noch eine Zeit dauern wird, bis Compiler eine derart gute semantische Optimierung machen können. Denn bei den Constructoren, die für die Fragestellung wichtig sind, sind in der Regel nicht trivial, sondern machen viel mit Speicherbelegung usw. Die Entschiedung, daß die Aktionen, die im Constructor gemacht werden. aus semantischer Sicht bedeutungslos sind, sollte schwer sein.
Ich komme ja auch durch folgende Überlegung darauf, daß es zwei Copyctor aufrufe sind:

C++:
int pop()
{
    int temp = top(); // Zwischenspeichern des obersten Elements, 1. copyctor
    ... // entfernen des obersten Elements
    return temp;  // Wenn Zuweisung an Variable, 2. copyctor
}


Erste Zeile machtmeiner meiner nach zwei Dinge deutlich: 1. pop macht mehr als das "...", sondern eben auch gleich das top noch mit. Designtechnisch fraglich, weil mehr gemacht wird als gefordert und dafür Aufwandgetrieben werden muß. 2. temp mit dem copyconstructor. erzeugt. Mich darauf zu verlassen, daß der Compiler dieses temp wegoptimiert (was ich nicht glaube), würde ich nicht; vielleicht in 20 Jahren, wenn da mehr Intelligenz in den Optimizern liegt.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
019
30.10.2003, 10:44 Uhr
(un)wissender
Niveauwart


Tja, mal schaun.
Was die Compiler angeht, sie kriegen es zumindets hin, nicht zwei oder drei Objekte zu erstellen, sondern belassen es bei einem, das ist schon mal was!
(Wenn man ihnen ein bißchen dabei hilft.)
--
Wer früher stirbt ist länger tot.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: