Diskussion:Stapelspeicher/Archiv/1

Prioritätswarteschlange

Ich vermisse einen Verweis auf einen double-ended-Queue, auch Prioritätswarteschlange oder zweiendige Warteschlange genannt. Eine Prioritätswarteschlange ist sowohl ein Heap als auch ein Stack, da man Elemente vom Anfang als auch vom Ende entnehmen kann. siehe auch Buch "Algorithmen" von Robert Sedgewick, ISBN: 3893193014 Ich hatte dies schon eingearbeitet, das wurde aber von Benutzer:Coma gelöscht. -- Shmia 11:42, 11. Okt 2005 (CEST)

Eine Prioritätswarteschlange ist etwas anderes als eine Warteschlange. Was eine zweiendige Warteschlange sein soll, erschließt sich mir nicht, zumindes nicht, wofür das gut sein soll. Was dass dann noch mit einem Stapelspeicher zu tun hat erst recht nicht. Eine Prioritäswarteschlange ist auch garantiert kein Stack. Elemente vom Anfang und vom Ende entnehmen zu können zeichnet weder einen Stack noch einen Heap (bzw. eine Prioritätswarteschlange) aus. Was in dem Buch steht, weiß ich nicht. Es ist entweder falsch, der Autor arbeitet mit anderen und insbesondere unüblichen Bezeichnungen oder du hast das Buch falsch verstanden. --Coma 15:19, 11. Okt 2005 (CEST)

Vielleicht sollte man es so formulieren - eine Deque ist eine allgemeinere Datenstruktur, die gleichzeitig als Stapelspeicher, als auch eine Warteschlange benutzt werden kann. Ich glaube soweit sind wir uns einig. Eine Prioritätswarteschlange kann nun ebenfalls zu einem Stapelspeicher werden, wenn die gepushten Dinge alle die gleiche Priorität haben. Ich denke, dies sollten wir eher weglassen. -- Shmia 17:31, 11. Okt 2005 (CEST)

Lesenswert-Diskussion Januar 06 (abgelehnt)

Pro Im Review kam nicht mehr viel, ich gehe also mal davon aus, dass er soweit schon ganz gut ist. Hab zwar selbst viel zu beigetragen, aber da das schon lange her ist, stimme ich trotzdem mal mit ab. --Koethnig 13:12, 18. Jan 2006 (CET)

Ich sehe da zu viele Überschneidungen mit LIFO, das sollte man sauberer Trennen um falsche verlinkungen zu vermeiden. (Und vielleicht können wir uns auf eine der Schreibweisen „Last-In-First-Out-Prinzip“ oder „Last-In/First-Out-Prinzip“ einigen.) -- Schnargel 20:15, 18. Jan 2006 (CET)

Hmm, was hat das mit der Wahl zu tun? Die Existenz eines anderen mögl. schlechteren Artikels kann ja nicht Einfluss auf diesen Artikel hier haben? Das eine ist eine Datenstruktur, das andere ein Prinzip. Die Datenstruktur arbeitet mehr oder weniger zufällig nach dem Prinzip. Was willst du da sauber trennen? Wenn man über das Prinzip spricht, verlinkt man dorthin, wenn man über die Datenstruktur spricht, verlinkt man zur Datenstruktur! --Koethnig 22:47, 18. Jan 2006 (CET)

Kontra Aus verschiedenen Gründen:
1. Die Behauptung, dass zwischen den im Artikel unterschiedenen Konzepten Stapel und Keller in der Praxis kein Unterschied sei, kann ich nicht nachvollziehen. Einen Keller (im Sinne des Artikels) kann man mit einer verketteten Liste implementieren, für einen Stapel braucht man ein Array, um konstante Zugriffszeit auf alle Elemente zu gewährleisten. Außerdem verändert es die Ausdrucksmächtigkeit eines Programms, ob es mit Kellern oder Stapeln arbeiten kann (Kellerautomaten bzw. Turingmaschinen).
2. Die Illustration ist unglücklich gewählt. Man könnte denken, dass ein Stapel nur gleichartige, nicht unterscheidbare Kisten aufnehmen kann.
3. Der Abschnitt Anwendungen enthält unnötige Duplizierungen. Dass ein Keller zur Realisierung von Unterprogrammen benutzt werden kann, findet man unter Mikroprozessoren, Moderne Programmiersprachen und Stapelsprachen, es ist aber jedesmal exakt das gleiche Prinzip. Dass man Keller beim Parsen von Programmiersprachen verwenden kann, ist schon durch die Beziehung zwischen Kellerautomaten und kontextfreien Sprachen klar (worauf unter Anwendungen aber nicht eingegangen wird), die genannten Beispiele (Compiler, Klammerausdrücke, Infix- und Postfixnotation) sind lediglich Beispiele für kontextfreie Sprachen. Die Abschnitte über stapelorientierte Sprachen und "moderne" Sprachen wie Java etc könnte man zusammenziehen.
4. Generell habe ich meine Zweifel, ob der Artikel genug Stoff hergibt, um lesenswert zu sein. Nicht dass das Thema Kellerprinzip uninteressant wäre, aber die interessantesten Aspekte sind bereits unter Kellerautomat und Parser verarbeitet.

Grüße, Ssch 23:44, 18. Jan 2006 (CET)

Kontra Liest sich holprig, Dinge aus verschiedenen Thematiken sind zusammengefasst. Beispiel im Abschnitt "Moderne Programmiersprachen": Die Aussage "erweitern den Mechanismus des Mikroprozessor oft" ist schräg, richtig ist, sie nutzen den Mechanismus in (normalster) ihrer eigenen Art und Weise. Stilistik ist schlecht, der Inhalt leidet damit. Das Stackprinzip überhaupt, dessen Hardwarerealisierung in einem Mikroprozessors und die Nutzung von Keller / Stapelspeicher in Algorithmen sind sehr verschiedene zu betrachtende Dinge, auch wenn sie dem selben Prinzip gehorchen. Als praktischer Informatiker mache ich mir übrigens über rekursive Prozeduren keine Gedanken, ich nutze sie einfach und bin mir ggf nicht mal bewußt, dass das rekursiv ist, ich möchte damit sagen, das Rekursivität aus dieser Sicht nichts besonderes ist, außer: bei sehr tiefer Rekursivität braucht man zuviel Stack, entweder crashed der gesamte Ablauf, oder es gibt einen Stackoverflow. Das heißt, das Problem des Einsatzes von rekursiven Aufrufen ist nicht das Prinzip (ob oder nicht, was besser) sondern die Abschätzung wie tief die Rekursivität ist. Das Problem der Stackgröße ist wichtig (sollte man mdst kurz erwähnen). Das sei nur eine Einschätzung in Kürze. Im Artikel Subroutine habe ich versucht prinzipiell und konkret darzustellen, wie der Compiler beim Aufruf von Subroutinen den Stack nutzt. Ich würd' auch etwas selbst überarbeiten, nach Rückmeldungen, und wenn ich Zeit finde. Mit freundlichen Grüßen --HartmutS 18:13, 5. Mär 2006 (CET)

QS - Mach mit! 23:25, 23. Jan 2006 (CET)

Name Kellerspeicher

Ich denke die Symbolik/Metapher "Keller"-speicher sollte in diesem Artikel ebenfalls kurz geklärt werden. Die meisten die davon zum ersten Mal hören werden wohl eher denken: "So ein Schmarrn, was hat denn ein Keller mit Informatik zu tun?"

Ich stelle mir das so vor, dass mit Keller zur Begriffsentstehungszeit sinnbildlich ein Kohlenkeller gemeint war, auf den man jedes Jahr die Kohlenlieferung schüttet und dann übers Jahr von oben die Kohlen absammelt zum verfeuern. Die untersten Kohlen sind also die ältesten und nicht zu sehen und können erst zuletzt verwendet werden (LIFO). Im Gegensatz zum Begriff Stapelspeicher ist eben beim Kellerspeicher nur das Oberste zu sehen, die anderen Elemente sind verdeckt. Da heute kaum noch jemand selbst mit Briketts Kachelöfen befeuert ist IMHO die Symbolkraft des Wortes Kellerspeichers geschwunden und stiftet eher Verwirrung.

Gast Peter (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 88.73.247.210 (Diskussion • Beiträge) 12:54, 27. Feb. 2007 (CET))

Da kann ich erzählen, wo der Begriff herkommt. Mein Doktorvater, Hans Langmaack, war Oberassistent bei Samuelson, also auch am Institut, wo Bauer war. Er war auch an dieser Entwicklung beteiligt und hat einen Buch zusammen mit Ursula Hill (die später Samuelson auch heiratete) geschrieben:

"Translation of ALGOL60" (mit A.A. Grau, U. Hill), Handbook for Automatic Computation, Vol I, Part b, Grundlehren der math. Wissenschaften, Band 137, 397 pp., Springer, Heidelberg (1967)

Er erzählte uns Doktoranden beim Essen einmal diese Geschichte:

Bei der Übersetzung von Ausdrücke haben sie eine Idee gehabt, den sog. "Klammergebirge" 
- also die  vollständige Klammerung - erst einzuführen, dann mit diesen LIFO-Prinzip den so 
entstandenen Ausdruck auszuwerten. 
Bauer zog gerade um in München und war dabei, Kartons in den Keller zu stapeln. Er berichtete 
die Forschungsgruppe, dass als er dabei war Kartons aufeinander zu stapeln und wieder abzubauen, 
um an Gegenstände ranzukommen, es ihn plötzlich durchfahren ist, dass man so die Ausdrücke auswerten 
kann. Sogar die Erstellung der Klammergebirge kann mit einem Stack geschehen.
Aber statt "Stapel" hat er nur an seinen "Keller" gedacht, weil er über den Vorgang dachte, 
die sich eben "einkellern" nennt.

Also keine Belege hierfür, aber es macht ja Sinn. --WiseWoman 12:23, 26. Okt. 2007 (CEST)

Anfang und Ende

Ich finde die Begriffe Top of Stack(TOS) und Bottom of Stack(BOS) sehr wichtig und würde vorschlagen die in das Bild ein zu bauen. --Reuti 19:30, 5. Aug. 2008 (CEST)

Ehrlich gesagt: noch nie gehört. --PeterFrankfurt 02:29, 6. Aug. 2008 (CEST)

sehr sehr komisch, wie nennst du den Anfang und das Ende des Stacks ? --Reuti 15:04, 11. Aug. 2008 (CEST)

Einfach Top und Bottom, ohne das "of Stack" dabei und ohne diese Abkürzungen, wobei vor allem TOS ja nun seit den 80ern für was ganz anderes steht. (Stacks gab's schon vorher, weiß ich.) --PeterFrankfurt 01:18, 12. Aug. 2008 (CEST)

Soweit ich weiß wird in vielen hardwarenahen Programmiersprachen dieser Begriff verwendet und auch benutzt. Beispiele Google Suche von TOS BOS (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von Reuti (Diskussion • Beiträge) 13:34, 12. Aug. 2008 (CEST))

Also ich habe nun wirklich viele Jahre lang in purem Assembler kommerziell programmiert (65xxx und Z80, lesenderweise beim C(++)-Debuggen noch ein paar weitere), aber diese Abkürzungen sind mir da nie über den Weg gelaufen. --PeterFrankfurt 00:27, 13. Aug. 2008 (CEST)

Sehr Sehr komisch, als Student bekommt man sowas in den Kopf gehackt und dann nichts :) Naja dann lassen wir die Diskussion fallen, denn Redicts bestehen ja von TOS und BOS zu Stapelspeicher. --Reuti 11:02, 13. Aug. 2008 (CEST)

Das wird hierbei mit den Unis so wie mit den Schweizer Kantonen sein: Das ist von Uni zu Uni verschieden... --PeterFrankfurt 22:27, 13. Aug. 2008 (CEST)

Mir ist TOS aus Forth sehr sehr geläufig. GuidoD 13:39, 4. Okt. 2008 (CEST)

Laufrichtung

Zitat: Der Stapel wächst "nach unten", in Richtung niedrigerer Speicheradressen. Dies ist historisch begründet: Legt man bei begrenztem Speicher den Stack an die höchstmögliche Adresse, minimiert man die Wahrscheinlichkeit, dass andere Programmdaten (die z. B. hinter dem Programm abgelegt werden) mit dem Stapel kollidieren.

Dieses historisches Phänomen ist zwar nicht falsch, erscheint mir aber in Hinsicht auf die ursächliche Laufrichtung des Stacks als barer Unsinn. Der Grund findet sich m.E. in der bei 8-Bit und 16-Bit Prozessoren weithin üblichen Basis-Index-Addressierung, und auch die heute übliche Intel-x86 Architektur kennt modrm-Befehle, bei der für einen Lade-/Speicherbefehl die Register SP,BP,etc als Basisregister mit einem (im Maschinencode eingeschriebenen) Offset verrechnet werden. Offsets, hier eben bei Callframes, werden in der Regel positiv angegeben, man greift also vom Basisregister in Richtung höherer Adressen zu. Daher ist es sinnvoll, neue Callframes an niederen Adressen starten zu lassen und direkt über den TOS-Zeiger mit hardcodierten positiven Indexwerten zu gehen. GuidoD 13:39, 4. Okt. 2008 (CEST)

Also ich weiß ja nicht, ob das so viel miteinander zu tun hat. Einen ganzen Frame aufmachen tut man ja (in alter Zeit, vor der Einführung dafür optimierter Befehle) durch ein Addieren bzw. Subtrahieren des Stackpointerregisters statt durch wiederholtes Pushen. Wenn man so rechnet, sind beide Richtungen eher gleichberechtigt. Und bei reiner Assemblerprogrammierung, wie sie in der Einführungszeit der Mikroprozessoren noch viel verbreiteter war, hat man sich wenig um Callframes geschert, sondern einzelne Variablen bzw. Register auf den Stack geschoben. --PeterFrankfurt 00:24, 5. Okt. 2008 (CEST)

Nicht Callframe-Creation sondern Callframe-Usage - der Callee kann Variablen via SP addressieren. GuidoD 06:00, 5. Okt. 2008 (CEST)

Ja, aber dazu muss der Frame erstmal da sein, sprich der SP um die Frame-Größe versetzt werden. Und dafür hatten ältere Prozessoren einfach keine eigenen Befehle, man musste entweder viele Pushs von Hand machen oder den SP in den Akku übertragen, dort rechnen und wieder zurück damit, Aufwand, den man nicht so gern trieb. Ich rede hier ja von direkter Assemblerprogrammierung, wie sie damals herrschte, und nicht von Compilerbauern. Man muss sich vor Augen führen, was es zur Einführungszeit der Mikroprozessoren für ein Umfeld gab: gar keins! Es gab neben Assemblern ein, zwei Basic-Interpreter und ein paar grandios scheiternde Hochsprachencompilerversuche (UCSD-Pascal irgendwer? Aua), und Anwendungssoftware hat sich in meinem Bekanntenkreis an der Uni damals ziemlich genau jeder zweite User von Null an selber programmiert. Callframes waren da noch gar nicht am Horizont zu sehen, bei Mikroprozessoren. Bitte also nicht die Technik, die sich erst später entwickelt hat, als allgemeingültig für alle Mikroprozessoren (auch die früheren) hinstellen. --PeterFrankfurt 01:17, 6. Okt. 2008 (CEST)

Postfixnotation

Von HP hatte ich mal einen Artikel, der zu dem Thema behauptete, daß ein Stack mit 4 Einträgen für jedes Problem in Postfixnotation ausreichend wäre. Hat da noch jemand die Quelle? Es ging damals um den HP41, der 4 Einträge in seinen Stack aufnehmen kann. --Harald Wehner 23:10, 28. Dez. 2008 (CET)

mathematisch gesehen ist diese Behauptung Unsinn, es ist ganz leicht, Gegenbeispiele zu konstruieren. HP hat möglicherweise etwas ähnliches gesagt, dann aber eher so in der Richtung "in der Praxis tauchen keine Probleme auf, die mit einem Stapel der Tiefe 4 nicht lösbar wären". Da wiederum gebe ich denen recht. --Herbert Klaeren 23:17, 28. Dez. 2008 (CET)

Klar, bei zu großer Komplexität muss man dann zurückgreifen auf Zwischenspeicherung von Hand in Variablen bzw. separate Speicherzellen, das geht alles, aber mit größerem Stack ginge es eleganter und schneller. --PeterFrankfurt 01:03, 29. Dez. 2008 (CET)

Wenn ich mich recht erinnere (das war vor über 20 Jahren!) ging es nur um die "normalen" arithmetischen Funktionen (auch sowas wie Funktionen, die auf einen Operanden angewendet werden, wie Sinus() und so weiter) und warum HP keine Klammern braucht. Damals waren bei den Taschenrechnern ja 10 oder 20 Klammerebenen en vogue. Ein Problem muß also so umformuliert werden, daß man es mittels 4-Ebenen-Stack lösen kann. Und die Behauptung war eben: Das geht immer - soweit ich mich erinnere. (Wie gesagt, über 20 Jahre...) --Harald Wehner 08:21, 29. Dez. 2008 (CET)

Also das kann ich mir nicht vorstellen, dass das immer gehen soll. Rein von der Logik her: Wenn mehr als drei (zwei Operanden, einer im Sinn), nämlich vier, Stackelemente gebraucht werden, dann gibt es bestimmt auch Fälle, wo man noch mehr braucht. Ich kann jetzt kein Gegenbeispiel aus dem Ärmel schütteln (Freiwillige, irgendwer?), aber das sieht nach einer sehr mutigen Behauptung aus, wobei man auch vorsichtig sein muss, ob HP selbst das überhaupt so behauptet hat. Ich habe übrigens nichts gegen HP, habe für meinen HP 25 (noch nix 25C) damals noch ungeheuer teure 548 DM bezahlt! --PeterFrankfurt 00:46, 30. Dez. 2008 (CET)

Aufrufstapel (Call Stack)

Ich denke, dass wir unbedingt eine deutsche Entsprechung zu en:Call stack brauchen, da dieser ein sehr wichtiges Werkzeug beim Abhandeln von Unterprogrammen ist. Viele Artikel, wie z. Bsp. Dynamischer Speicher verweisen auf diesen Artikel, obwohl dort nicht die Datenstruktur, sondern der Aufrufstapel im Hauptspeicher gemeint ist. --Kockster 15:35, 9. Jul. 2008 (CEST)

Stimme dem voll und ganz zu. Ich bin eigentlich auf der Suche nach dem Call Stack bei diesem Artikel hier gelandet. Und in der Einleitung steht, dass der Stack von der Hardware unterstützt wird... das bezieht sich doch auf den Call Stack oder etwa nicht? Wenn ich mir meinen eigenen Stack programmiere, dann hat der doch keine Hardware-Unterstützung. Es sieht also für mich so aus, als sei dieser Artikel zumindest irgendwann mal in der Absicht verfasst worden, den Call Stack und nicht die Datenstruktur zu beschreiben. --GGShinobi (Diskussion) 22:52, 3. Jul. 2012 (CEST)

der call stack heisst auf deutsch Laufzeitstapel, und natürlich kannst du, wenn du Assembler programmierst, auch den Hardwarestack für eigene Zwecke verwenden, solange du keine Unterprogrammsprünge verwendest. Für die höheren Programmiersprachen ist der Hardwarestack natürlich unsichtbar, weil die ihn wirklich für die Implementierung eines Laufzeitkellers brauchen. Stapelspeicher ist aber ein ganz allgemeines Prinzip und übrigens praktisch die einzige Datenstruktur, die im Prinzip durch ein deutsches Bundespatent aus dem Jahr 1959 geschützt ist. --Herbert Klaeren (Diskussion) 23:12, 3. Jul. 2012 (CEST)

Schieflage

Vorsicht Freunde, die Seite hat Schräglage! Der Stack ist eine der ältesten Errungenschaften der Mikroprozessorei. Es handelt sich um Hardware. Er diente und dient noch immer dazu, den Programmzähler (PC, programm counter) bei Unterprogramm-Aufrufen zu stellen. Da man i.a. nur ein RAM zur Verfügung hat, man aber neben den Adressen angesprungener UPs auch Daten speichern will, schreibt man die Daten im Adressbereich von unten nach oben (hintereinander), den Stack hingegen von oben nach unten (rückwärts beginnend beim RAM-Ende RAMEND).

Dazu ermittelt man im ersten Schritt jedes Programms die Größe des RAM und setzt den Stapelzähler (stack pointer - SP) darauf. Der Rest passiert automatisch beim Aufruf von Unterprogrammen. Der Stack Pointer wird beim Einstieg (RCALL irgendwas) in ein Unterprogramm (Hardware) erniedrigt, beim Ausstieg mit RET oder RETI wird er wieder erhöht. Das geht vollautomatisch, i.a. ohne daß der Programmierer darauf Einfluß nimmt.

STACK initialisieren am Beispiel ATMEL ATmega8
ldi r16, LOW(RAMEND)      ; LOW-Byte der obersten RAM-Adresse
out SPL, r16              ; Setze SP low-Teil
ldi r16, HIGH(RAMEND)     ; HIGH-Byte der obersten RAM-Adresse
out SPH, r16              ; Setze SP high-Teil

RAMEND ist in einem prozessorspezifischen File vereinbart (Assembler: m8def.inc oder C-Header iom8.h) z.B. als

.equ RAMEND = 0x045f ; start of stack pointer (läuft rückwärts)

Gäbe es keinen Stack, so gäbe es in Assembler nur RJMP und kein automatisches RETURN nach einem RCALL. Der Stack merkt sich also die Rücksprungadresse aus einem Unterprogramm.

-- Heinzelmann 15:09, 1. Apr. 2009 (CEST)

Hmm, das ist jetzt Atmel, ähnlich wie bei x86 oder 8080 oder so. Z. B. für meinen geliebten 6502 stimmt das alles überhaupt nicht, da dessen Stack auf die Page 1 fixiert ist (aber auch von oben nach unten wächst). Also sind Deine Ausführungen schon mal nicht allgemeingültig. Und der Stack an sich ist auch keine Errungenschaft der Mikroprozessoren, den gab es auch schon vorher bei den diskreteren Computerhardware-Varianten. Und unter den Mikroprozessoren gibt es mindestens einen, den SC/MP, der hat überhaupt keinen Subroutine-Call, das mussten Programmierer sich aufwendig zu Fuß basteln (kenne ich aber nur vom Hörensagen). Wie gesagt, wir müssen hier allgemeingültig bleiben und uns deshalb auf den kleinsten gemeinsamen Nenner beschränken. --PeterFrankfurt 01:22, 2. Apr. 2009 (CEST)

PeterFrankfurt hat völlig recht, die Ausführungen von Heinzelmann sind sehr spezifisch auf eine bestimmte Prozessorfamilie bezogen. Und der Stack ist zwar bei modernen Mikroprozessorarchitekturen normal, aber das Konzept ist viel älter. Das steht auch ausdrücklich im Artikel. --Herbert Klaeren 08:57, 2. Apr. 2009 (CEST)

"Mithilfe des Stapelspeichers lassen sich einfach Terme oder Syntaxen auf richtige Verschachtelung prüfen, so wie es oft im Internet bei BB-Codes oder XML-Dokumenten der Fall ist."

Wie denn? Erschließt sich mir nicht. --213.221.250.85 16:43, 7. Dez. 2010 (CET)

Der Satz kommt mir auch ziemlich schräg formuliert vor. Was gemeint ist, ist die Überprüfung von Klammerstrukturen, dass also zu jeder "Klammer auf" eine entsprechende "Klammer zu" gehört. Das kann man natürlich auch mit einem Stapelspeicher überprüfen: bei "Klammer auf" push, bei "Klammer zu" pop - im Fall von XML nur dann, wenn es das richtige "closing tag" ist. Dann muss hinterher der Stapel leer sein... --Herbert Klaeren 19:43, 7. Dez. 2010 (CET)

Implementierung

Die angegebene Implementierung ist sinnlos. Ein Stack, der durch ein Array implementiert ist, könnte direkt durch ein Array ersetzt werden. Man sollte ein Beispiel eines richtigen Stacks mit Zeigern einbauen. -- Mfnalex 19:29, 10. Jan. 2012 (CET)

Ich habe die Implementierung durch einen Stack der mit Zeigern arbeitet ersetzt. --PrototypePHX (Diskussion) 17:37, 30. Jun. 2012 (CEST)

ja, aber das ist hier trotzdem kontraproduktiv. Der Witz beim Stack ist ja gerade der, dass er sich extrem leicht verwalten lässt, man braucht im Prinzip nur einen Index in einem Array zu verwalten. Alle eingebauten Hardware-Stacks (z.B. beim Intel) arbeiten genau so. Die Version mit den verzeigerten Listen ist größenordnungsmäßig komplizierter. Was Mfnalex hier als „richtigen Stack mit Zeigern“ bezeichnet, ist gar kein Stack, sondern - spätestens in deiner Implementierung - eine verzeigerte Liste. --Herbert Klaeren (Diskussion) 19:16, 30. Jun. 2012 (CEST)

Stimmt, ist mir beim Programmieren dann auch aufgefallen, habe mir aber nichts weiter dabei gedacht. Kopierkonstruktor und Zuweisungsoperator sind deswegen ja auch nicht besonders hübsch ... --PrototypePHX (Diskussion) 20:39, 30. Jun. 2012 (CEST)

Richtung

Im Text steht: "Der Stapel wächst also nach unten." heißt das, Richtung kleinere Speicheradressen? - "Der Stapel wächst also nach unten, in Richtung der kleineren Speicheradressen." könnte man doch dann schreiben. --Ost38 11:31, 23. Feb. 2008 (CET)

Auslegeschrift

Hallo,

ich habe gerade das hier gefunden: Auslegeschrift 1 094 019. Kann man das vielleicht bei den Commons hochladen? Kennt sich da jemand aus?

Grüße, --Martin Thoma 11:57, 4. Aug. 2012 (CEST)

Als „amtliche Bekanntmachung“ müsste das gehen (Wikipedia:Bildrechte #Amtliche Werke); 1957. Dort ggf. nachfragen (FAQ). Sonst: Einfach rauf damit; Reaktion abwarten, runterwerfen kann das dann immer noch jemand.

Statt direkt international hochzuladen und sich mit den Rechten auf Commons zu plagen, erst mal auf deWP hochladen und die weitere Commonsfähigkeit durch Experten beurteilen lassen.

Name: Auslegeschrift, Patent 1094019, Verfahren zur automatischen Verarbeitung von kodierten Daten.pdf

Lizenz: Vorlage:Bild-PD-Amtliches Werk

Autoren: Friedrich Ludwig Bauer, Klaus Samelson

Selbermachen ist nicht schwer und übt: Hier klicken.

Interessante Fundsache, nebenbei. Jetzt weiß ich, warum man zum Lachen in den Keller geht --PerfektesChaos 15:33, 4. Aug. 2012 (CEST)

Abschnitt "Compiler"

So, wie der Abschnitt vorher war, hat er Compile-Zeit und Laufzeit vermischt. Ich habe den Laufzeit-Teil nach oben verschoben. Außerdem war die Darstellung des Parsing-Prozesses falsch. Ich habe sie darum entsorgt und statt dessen auf Kellerautomat verlinkt. Wäre es evtl. besser, auf entsprechende Parsing-Algorithmen zu verlinken? -- UKoch 18:55, 21. Nov. 2011 (CET)

Tippo im Zitat

Ich habe soeben einen vermeintlichen Tippo („Samuelson“ statt richtig „Samelson“) korrigiert, allerdings in einem Zitat: Fußnote 1 zu ISBN 3-540-11722-9, S. 222. Es besteht also leider die Möglichkeit, daß das Zitat selber den Tippo enthielt. In dem Fall sollte der Fehler stehen bleiben. Es wäre schön, wenn jemand in ISBN 3-540-11722-9, S. 222 nachsehen könnte, ich habe keinen Zugriff darauf. --H.Marxen (Diskussion) 13:54, 27. Aug. 2013 (CEST)