Diskussion:Dynamischer Speicher/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Dynamischer Speicher/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Dynamischer_Speicher/Archiv#Thema_1

BSS

Ich habe gelesen, dass BSS nicht nur mit "Block Started by Symbol", sondern auch mit "Block Static Storage" oder "Blank Storage Segment" erklärt wird - wo findet man dazu genauere Angaben? -- 217.232.99.200 17:19, 20. Feb 2005 (CET)

das kann jeder autor halten wie er will... kann auch "bestimmt super saugfähig" heißen... --Heimschützenzentrum (?) 10:29, 12. Jul. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Heimschützenzentrum (?) 12:18, 14. Nov. 2012 (CET)

Nochmal: Begrifflichkeit

Dieser Artikel vermischt m. E. die Begriffe "Heap" (im Sinne von Haldenspeicher) und die allgemein "dynamische Speicherallokation" (im Sinne der Allokation von Hauptspeicherbereichen während der Laufzeit).

Ich finde, diese beiden - hier vermischten Bedeutungen - sollten extrahiert werden und in zwei getrennte Artikel (dito) ausgelagert werden. Evtl. gibt es da auch noch Überlappung mit "Allokation (Informatik)" und "Speicherverwaltung". -- Plankton314 (Diskussion) 16:47, 9. Nov. 2012 (CET)

1. kannst du bitte kurz den unterschied zwischen „dynamischen Speicher“ und „Heap“ umreißen? möglichst mit quellen gemäß WP:Q... 2. und die „dynamische Speicherallokation“ ist ganz einfach die Allokation von Heap-Space... dafür braucht man doch keinen gesonderten Artikel... --Heimschützenzentrum (?) 20:40, 9. Nov. 2012 (CET)

Ich sehe gerade, es sollte genügen, den Abschnitt "Speicherverwaltung" mit dem bereits existierenden Artikel dazu zu mergen. Der Rest passt eigentlich. -- Plankton314 (Diskussion) 22:24, 9. Nov. 2012 (CET)

ach so... eine plötzliche meinungsänderung gefolgt von einem umfangreichen edit... 1. warum musste der verweis auf echtzeit anwendungen weg? 2. wir sollen ja nicht jeden doppelten inhalt löschen... 3. können wir das wieder rückgängig machen? --Heimschützenzentrum (?) 08:42, 10. Nov. 2012 (CET)

Warum sollte ich meine Meinung nicht ändern können, wenn ich sehe, dass meine Ansicht nicht richtig war?

Der entfernte Abschnitt den du mit "Echtzeit-Anwendungen" wahrscheinlich meinst, ist vollkommen diffus. Ich erwarte zu sowas ja nicht mal eine Quelle, aber dann zumindest eine halbwegs sinnvolle Ausführung.

Das Einzige, was rausgeflogen ist, sind die beiden Abschnitte mit - m. E. etwas umständlichen - Erklärungen für verschiedene Platzierungsstrategien. Die sind jedoch im Artikel "Virtuelle Speicherverwaltung" erklärt, weswegen ich auch einen Verweis dazu hinzugefügt habe.

Man kann überlegen, ob die Erklärungen hier auch noch reinsollen, dadurch bauen wir jedoch eher Redundanz auf. -- Plankton314 (Diskussion) 12:03, 10. Nov. 2012 (CET)

1. oops - WP:RED hatte ich irgendwie anders in erinnerung... 2. Echtzeit-Anwendungen sind immer interessant und man sollte schon kurz darauf verweisen... Wie wäre so ein Satz: „Für Echtzeit-Anwendungen kann dynamische Speicherverwaltung ungeeignet sein.“? --Heimschützenzentrum (?) 12:18, 10. Nov. 2012 (CET)

Getan. Was noch? -- Plankton314 (Diskussion) 16:38, 11. Nov. 2012 (CET)

sonst ist mir kein unschöner unterschied aufgefallen... --Heimschützenzentrum (?) 17:37, 11. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Heimschützenzentrum (?) 12:18, 14. Nov. 2012 (CET)

heap / freispeicher

hallo, ich habe zwar nicht so den einblick in die materie aber der artikel scheint mir in einem punkt missverstaendlich; erst steht da "Der dynamische Speicher, auch Heap (engl. für Halde, Haufen) oder Freispeicher..." und etwas weiter unten liest man "In C++ wird manchmal zwischen Heap und Freispeicher unterschieden". moeglichweise ist das ja richtig, wenn man weiss wie es gemeint ist aber mir als halblaien ist nicht klar was das genau bedeutet. mfg, armin --(nicht signierter Beitrag von 213.235.233.66 (Diskussion) 10:31, 11. Aug. 2005 (UTC))

hat sich erledigt... wenn es einen unterschied gibt, wäre er zu unwichtig für uns... --Heimschützenzentrum (?) 10:29, 12. Jul. 2010 (CEST)

malloc()/free() <-> new/delete

Die Beschreibung von malloc() und free() einerseits und new/delete andererseits ist nicht so ganz glücklich (siehe bereits exisatierende Kommentare).

Entweder würde ich das ganz weglassen (die Unterscheidung mehrerer Varianten in einer konkreten Sprache ist vielleicht zu detailliert für diesen Artikel) oder korrekt beschreiben (beide Varianten arbeiten in aller Regel auf demselben Speicher, dem Heap, allerdings wird bei malloc() nur Speicher reserviert, während bei new auch zugehörige Konstruktoren aufgerufen werden; entsprechend wird bei free() nur freigegeben, während bei delete die Destruktoren vorher laufen).

--Mfgkw 13:51, 30. Nov. 2006 (CET)

Was heißt Speicheranforderung?

Von wem wird denn der Speicher angefordert? Warum muss Speicher angefordert werden? Ein Computer hat doch eine genau festgelegte Größe des Arbeitsspeichers? -- 84.138.253.253 11:46, 23. Okt. 2008 (CEST)

wo steht das denn undeutlich im artikel? es ist so, dass der Arbeitsspeicher auf die einzelnen programme aufgeteilt wird, da man weder nur einem programm den ganzen speicher geben will (das wär zeit aufwändig, wenn man den speicherinhalt jedesmal, wenn ein anderes programm ihn braucht, auswechseln muss...), noch allen programmen den ganzen speicher geben will (dann würden die sich vllt gegenseitig stören - es wäre jedenfalls aufwändiger)... stichwort: multitasking --Heimschützenverein 13:58, 23. Okt. 2008 (CEST)

Abschnitt "Speicherverwaltung" / Komplexität Heap im Vergleich zum Stack

@Benutzer:Homer_Landskirty: Das die Speicherverwaltung eines Heap "wesentlich" komplizierter ist als die des Stack, ist keine unzulässige Wertung, sondern eine Tatsache. Nicht umsonst spricht man beim Stack ja auch von "automatischer" Speicherverwaltung, weil sie so einfach ist, dass der Computer das schon fast "von alleine" machen kann. Das ist beim Heap nicht der Fall. Auch der Abschnitt "da das Anfordern und Freigeben von Speicherabschnitten völlig dynamisch und unvorhersehbar erfolgen kann" ist völlig korrekt. Je nachdem, welches Scheduling eingesetzt wird. Ich kann allerdings Deinen Einwand nachvollziehen und werde darum jetzt eine Kompromisslösung machen, die sowohl den vorhergehenden als auch Deinen Text umfasst. -- GGShinobi 11:51, 1. Mai 2010 (CEST)

hm? "wesentlich" würde für mich bedeuten, dass irgendwelche knobelaufgaben zu lösen wären (bsp: schachspiel ist wesentlich komplizierter als tic-tac-toe)... das ist hier jedoch nicht der fall, so dass der computer alles _automatisch_ und mit wenig aufwand (höchstens linearer aufwand durch das suchen in (kurzen) listen) erledigen kann... und "völlig dynamisch" würde für mich bedeuten, dass das programm sich in unvorhersehbarer weise ändert... dies ist jedoch praktisch nie der fall, so dass durch das programm eben viel dynamik/chaos verloren geht... wohl aber kann man vorab schlecht sagen, wo lücken im speicher entstehen werden, was ja bereits durch "nicht notwendig kompakt" ausgedrückt wird... ich find die änderung also nach wie vor unpassend und reißerisch... --Heimschützenzentrum (?) 12:19, 1. Mai 2010 (CEST)

kompakte Speicherabschnitte

Was heißt kompakt? --194.138.12.146 08:43, 12. Jul. 2010 (CEST)

"kompakt" heißt hier: wenn man beliebige zwei benutzte Bytes nimmt, dann sind die dazwischen liegenden auch benutzt... --Heimschützenzentrum (?) 09:30, 12. Jul. 2010 (CEST)

Wo wird das erklärt? Wäre da "zusammenhängend" nicht selbsterklärend? --194.138.12.146 09:36, 12. Jul. 2010 (CEST)

buchstäblich heißt es "zusammengepackt" laut Wikipedia... wikt:kompakt... bei "zusammenhängend" drängt sich mir die idee einer reihenfolge auf (so wie zugwagons)... --Heimschützenzentrum (?) 10:23, 12. Jul. 2010 (CEST)

Lücken dürfen nach dieser Definition bei "kompakt" also schon sein, aber nur sehr kleine, etwa so wie bei einer dichtesten Kugelpackung. Ansonsten: hat der Speicher keine Reihenfolge (so wie Zugwagons)? --194.138.12.146 10:37, 12. Jul. 2010 (CEST)

nein, hier ist kompakt in seiner Definition ohne Lücken zu verstehen... macht ja auch anders im Kontext keinen Sinn (denn: es geht ja anders als bei Kugeln...)... es geht ja im Kontext hier um "Speicherabschnitte", die eben keine Reihenfolge haben müssen... --Heimschützenzentrum (?) 11:00, 12. Jul. 2010 (CEST)

Umgekehrt: weil "kompakt" (dicht gefügt, ohne große Zwischenräume) ausdrücklich Lücken erlaubt, sagt es in diesem Kontext etwas anderes als eigentlich gemeint ist. PS: Gefallen dir die Wörter "lückenlos" oder von mir aus "unfragmentiert" besser als "zusammenhängend"? --194.138.12.145 12:59, 12. Jul. 2010 (CEST)

PPS: Wieso haben "Speicherabschnitte" keine Reihenfolge? Sie sind doch offensichtlich in der durch ihre Adressen definierten Reihenfolge geordnet. --194.138.12.146 13:06, 12. Jul. 2010 (CEST)

das würde ich mal dem Leser zutrauen, dass er bei "dicht gefügt" nicht an "mit lücken" denkt... "zusammenhängend" ist besser als "lückenlos" und "unfragmentiert"... wie wär denn statt "die verwendeten Speicherabschnitte nicht notwendig kompakt sein müssen" das hier: "zwischen den verwendeten Speicherabschnitten unverwendete Lücken sein können"? --Heimschützenzentrum (?) 15:36, 12. Jul. 2010 (CEST)

Mit "zwischen den verwendeten Speicherabschnitten unverwendete Lücken sein können" bin ich einverstanden, wobei allerdings meines Wissens ja eher die Lücken in den unverwendeten Speicherabschnitten das Problem sind (wenn 100MB frei sind und 1MB angefordert wird, muss 1MB lückenloser Abschnitt in den 100MB gefunden werden). --194.138.12.144 15:51, 12. Jul. 2010 (CEST)

Abschnitt Speicherverwaltung u.a.

Ich habe am 21.11.2010 versucht, den Abschnitt Speicherverwaltung etwas besser zu formulieren (siehe hier). Homer Landskirty hat meine Änderung mit der Begründung

hier geht es um dynamische speicherverwaltung... virtueller speicher hat damit nix zu tun...

rückgängig gemacht.

Zum einen finde ich es für das Verständnis der Speicherverwaltung wesentlich, zu wissen, dass es sich um virtuelle Adressen handelt, zum anderen habe ich nicht nur auf den virtuellen Speicher verwiesen, sondern auch die Zuteilungsstrategie imho besser erklärt, als es momentan der Fall ist.

By the way: Ob mein C++ Beispiel zu speziell ist, darüber diskutiere ich gerne. Aber wo im Abschnitt 1 steht, dass eine Stack Variable ihre Gültigkeit verliert, wenn die Funktion verlassen wird, und eine Heap-Variable nicht, kann ich leider nicht finden. (Man könnte es sich zwar mit dem was in Unterstützung von dynamischen Speicheranforderungen in Programmiersprachen steht u.U. selbst herleiten, aber Wikipedia ist ja kein reines Stichwortverzeichnis zum selbst Weiterdenken.)

Ich würde mich über Meinungen dazu freuen. Insbesondere natürlich von Homer Landskirty. Momentan bin ich jedenfalls der Meinung, dass der aktuelle Artikel schlechter als die Form nach meinem letzten Edit ist.

--5gon12eder 03:01, 23. Nov. 2010 (CET)

1. „Unterschied zum Stack“ Abschnitt: Der mag zwar etwas merkwürdig sein (z B „Speicherfresser“)... aber das ist kein grund noch einen merkwürdigen abschnitt zu machen (z B ist es nicht ganz klar, ob ein funktionsaufruf in einem Bereich diesen Bereich „verlässt“)... und das beispiel ist ja bei näherer betrachtung auch noch falsch (warum sollte nicht ordentlich beanspruchter speicher „0“ sein?)...
2. „Verständnis der Speicherverwaltung wesentlich, zu wissen, dass es sich um virtuelle Adressen“: mag sein, _aber_ es geht hier um „dynamischen speicher“ und nicht allg um Speicherverwaltung... bei dem Heap isses nämlich ganz egal, ob da noch ne abbildungs schicht zwischen dem echten speicher kommt oder nich... für den heap ist es eben ein addressraum mit adressen einer bestimmten breite...
3. „Zuteilungsstrategie“: zu den strategien steht in den verlinkten artikeln ja schon genug (es fehlt z B die stack-artige bei GC mit automatischer kompaktifizierung oft zu findende...)... gerade diese links fehlten in dem komplett umgeschriebenen absatz...

--Heimschützenzentrum (?) 08:47, 23. Nov. 2010 (CET)

ad (1): (a) Ein Funktionsaufruf verlässt im Sinne der Variablengültigkeit definitiv den Bereich, aus dem die Funktion aufgerufen wurde. Innerhalb der Funktion kann man wohl nicht auf unmittelbar vor ihrem Aufruf deklarierte Variablen zugreifen, oder? (b) Warum der Ausgabewert „0 sein soll“, kann ich Dir leider nicht sagen. Aber wenn ich den Code auf meinem Rechner (Ubuntu 10.04) compiliere (g++ 4.4.3) und ausführe, wird 0 ausgegeben. Ich habe nicht explizit im C++ Standard nachgelesen und es ist für diesen Zweck ja auch egal. Wichtig ist, dass der Wert der Variable weg ist.

ad (2): Weshalb stört Dich in meinem Text, dass ich darauf hinweise, dass effiziente Speichernutzung trotz Verwendung virtuellen Speichers wichtig ist, aber nicht dieser Satz, der bereits im Artikel steht:

„Der Grund ist, dass auch der virtuelle Adressraum, auf den sämtliche Adressen abgebildet werden müssen, nicht unbegrenzt ist. Bei einem 32-Bit-Betriebssystem (d.h. bei einem System mit 32-Bit breitem Adressbus) hat der virtuelle Adressraum je Prozess eine Maximalgröße von 2³² Adressen (das entspricht 4 GiB (Gibibyte)), von denen das Betriebssystem selbst gewöhnlich einen erheblichen Anteil für sich beansprucht.“

Das ist im Wesentlichen der gleiche Inhalt aber in schlechterem Deutsch. Und ich verstehe nicht ganz, weshalb man dem Leser nicht erklären dürfen soll, weshalb man den Speicher effizient nutzen will und weshalb man es trotz virtuellem Speicher tun will.

ad (3): Ich finde im aktuellen Artikel genau 2 Strategien: Best-Fit und Worst-Fit. Dagegen habe ich sogar zwei mehr erwähnt, die jetzt wieder fehlen. Und wenn Dir etwas fehlen sollte, was hält Dich dann davon ab, das Fehlende zu ergänzen? Und mit Kompaktifizierung kann ich im Bezug auf dynamischen Speicher nicht viel anfangen, denn Speicherblöcke verschieben geht definitiv nur so, dass der Prozess nichts davon mitbekommt, da sonst ja alle Pointer kaputt wären.

--5gon12eder 23:56, 25. Nov. 2010 (CET)

1. (a) sehe ich anders... man kann ja der aufgerufenen funktion einen zeiger auf den stack bereich mitgeben... macht man ja bei heap speicher auch... (b) das ist ja nun WP:OR... solche beispiele verwirren zu sehr, glaub ich...
2. hat mich sicherlich auch schon mal gestört... da jetzt der satz (wieder) zur disk steht, habe ich den absatz mal etwas kompaktifiziert als bessere diskussionsgrundlage (obwohl es bei der beurteilung gewisser edits eher egal ist, was andere schonmal gemacht haben...)... besseres/schlechteres deutsch sehe ich jetzt gerade nicht... besonders ungut fand ich wohl die größere länge durch die zahlreichen thema-fremden abschweifungen...
3. es stand ja schon da... warum soll ich das schlechter neue auf den alten stand bringen? zur kompaktifizierung kann man ja in den anderen artikeln genug nachlesen (z B könnte der compiler informationen zur datenstruktur hinterlegen oder man benutzt eine abbildungsschicht beim dereferenzieren... ist aber egal für den artikel...)...

--Heimschützenzentrum (?) 08:31, 26. Nov. 2010 (CET)

Lassen wir das Programmbeispiel mal. Mit dem Speicherverwaltung Abschnitt bin ich jetzt aber gar nicht mehr glücklich:

• Die Erklärung von best- und worst-fit sind einfach falsch. Denn so wie es momentan im Artikel steht, klingt es, als würde die vollständige Lücke reserviert. Wenn wir die Strategien überhaupt im Artikel haben wollen, möchte ich noch mal meine Formulierung einbringen:

1. Best Fit Strategie: Es wird ein Teil in der kleinsten Lücke reserviert, die groß genug ist, um die gestellte Anforderung zu erfüllen. (Vorteil: große Lücken bleiben erhalten. Nachteil: Es wird immer unwahrscheinlicher, dass die verbleibenden sehr kleinen Lücken noch jemals verwendet werden können.)
2. Worst Fit Strategie: Es wird ein Teil in der größten noch freien Lücke reserviert. (Vorteil: Es werden so wenig kleine Lücken wie möglich geschaffen. Nachteil: Große Lücken werden systematisch zerstört.)

Aber warum sollte man ausgerechnet diese beiden erwähnen, und andere nicht?

• „Ohne automatische Speicherbereinigung kann es durch Fragmentierung des zur Verfügung stehenden, endlich großen Gesamtspeicherbereiches so weit kommen, dass neue Speicheranforderungen nicht mehr erfüllt werden können, obwohl der insgesamt verfügbare freie Speicher noch ohne Weiteres ausreichen würde.“
  Da werden doch zwei Dinge vermischt. Das eine ist Fragmentierung, die dazu führt, dass zwar noch viel Speicher frei ist, aber immer nur in kleinen Stücken, so dass große Anforderungen nicht mehr bedient werden können. Abhilfe schafft hier nur eine bessere Zuteilungsstrategie, automatische Speicherbereinigung löst das Problem nicht. Das andere Problem ist, wenn nicht mehr benötigter Speicher nicht freigegeben wird. Dann wird auch ohne Fragmentierung irgendwann der komplette Speicher voll und es kann gar keine Anfrage mehr bedient werden. (In der Tat wäre ein Speicher, in dem nie etwas freigegeben wurde ja sogar gänzlich unfragmentiert, da einfach immer ans Ende geschrieben und die bereits reservierten Blöcke behalten werden.)
• Die beiden letzten Abschnitte haben eigentlich nichts mit Speicherverwaltung (wenn ich darunter mal die Routinen des Betriebssystems verstehe) zu tun, und sind in diesem Abschnitt daher etwas fehl am Platz.
• Den Link auf Geschwindigkeit habe ich gleich mal entfernt. Denn mit dx/dt hat das hier wohl eher nichts zu tun. Aber ich frage mich bei dieser Aufzählung generell, was sie dem Leser bringen soll.

Vielleicht sollten wir ganz damit aufhören, zu versuchen, den vorhandenen Artikel (der imho ein nahezu verlorener Fall ist) zu verbessern, und ihn stattdessen von Grund auf neu schreiben. In der englischen WP steht das ganze auch unter dem Lemma „Dynamische Speicherzuteilung“ was zu übernehmen ich eine Überlegung wert fände.

--5gon12eder 11:47, 27. Nov. 2010 (CET)

1. die erklärung von "worst fit" habe ich etwas überarbeitet... da war ja nur ein wort missverständlich...
2. eine aufzählung muss ja nicht vollständig sein... die beiden angerissenen sind wohl am gebräuchlichsten...
3. da geht es eben um fragmentierung, die durch die bei automatischer speicherbereinigung vorkommende kompaktifizierung beseitigt wird...
4. die beiden letzten Abschnitte setzen eben die dyn. speicherverwaltung in einen weiteren kontext... warum sollte das da nicht hinpassen? wir schreiben ja keine anleitung für betriebssystem programmierer...
5. bei totalem neuschreiben bin ich immer etwas skeptisch, weil das neue wieder neue fehler hat, während das alte kontinuierlich über jahre verbessert wurde...
6. „Dynamische Speicherverwaltung/Dynamische Speicherzuteilung“: warum soll man das an den algorithmen und nicht am gegenstand festmachen können? n redirect reicht da wohl...

--Heimschützenzentrum (?) 22:48, 27. Nov. 2010 (CET)

Was meinst Du mit „die bei automatischer speicherbereinigung vorkommende kompaktifizierung“? Automatische Speicherbereinigung heißt, dass ein Objekt automatisch gelöscht wird, wenn es das letzte Mal verwendet wurde. Dabei entstehen sogar Lücken. Kompaktifizieren bedeutet, dass Speicherblöcke zusammengeschoben werden, um zu defragmentieren. Letzteres wird im Heap aber definitiv nicht gemacht. Sonst würden einmal definierte Pointer ja unsinnig, wenn jemand im Speicher herumschiebt, ohne dass der Prozess davon mitbekommen kann.

Was die Zuteilungsstrategien betrifft, blicke ich bei Deiner Argumentation leider nicht mehr durch. Einmal hältst Du mir vor, eine unvollständige Aufzählung gemacht zu haben, dann argumentierst Du, dass man nur zwei erwähnen müsse, wieder ein andermal sollte überhaupt nur auf die anderen (welche?) Artikel verwiesen werden. Da komme ich nicht mehr mit.

--5gon12eder 05:03, 28. Nov. 2010 (CET)

1. kompaktifizierung ist teil moderner automatischer speicherbereinigung... hab ich oben schon erklärt wie das geht... ist eben so... lies den entsprechenden artikel bitte... link ist im hiesigen artikel... :-)
2. es gibt eben wichtige Zuteilungsstrategien und weniger relevante... die immer hinten dranhängen, ist wohl eine der wichtigsten (java?), IIRC... --Heimschützenzentrum (?) 08:55, 28. Nov. 2010 (CET)

Natürlich kompaktifiziert ein modernes Betriebssystem, aber nicht im Heap so wie ihn der Prozess sieht, sondern eine Ebene tiefer bei der Abbildung auf den physikalischen Speicher. Das war ja mit ein Grund, weshalb ich gerne erwähnt gehabt hätte, dass der Heap im virtuellen Speicher liegt. Wo hast Du „erklärt, wie das geht“? Was „immer hinten dranhängen“ sein soll, weiß ich nicht. Steht aber wohl auch nichts im Artikel dazu.

Wie auch immer. Ich habe diesen Artikel jedenfalls mal für die Qualitätssicherung eingetragen und werde mich selbst wieder anderen Artikeln zuwenden. Vielleicht haben andere Leute ja noch andere Meinungen.

--5gon12eder 08:01, 29. Nov. 2010 (CET)

artikel automatische Speicherbereinigung gelesen? es werden in modernen automatischen speicherverwaltungen tatsächlich einzelne objekte verlagert, nur um lücken zu vergrößern/schließen... so! :-) QS ist ok... --Heimschützenzentrum (?) 09:16, 29. Nov. 2010 (CET)

Grundbegriffe

Liebe Kollegen!

1. Das Lemma "Dynamischer Speicher" finde ich nicht besonders glücklich, z.B. weil es (wie im Artikel geschehen) dazu verführt, allzu früh die Gleichsetzung
         Dynamischer Speicher = Heap
   zu vollziehen. Besser finde ich ein Lemma "Dynamische Speicherzuordnung" (=engl. "dynamic memory allocation"), notfalls auch das im Artikel vorkommende "dynamische Speicheranforderung".
2. Die Datenstruktur "Heap" (=engl. "heap"), die als Datenstruktur mit dem "Stack" vergleichbar wäre, hat nicht allzu viel zu tun mit dem hier verwendeten Heap. Abgesehen davon, gibt es viele unterschiedliche Typen von Datenstrukturen, mit denen Dynamische Speicherzuordnung realisierbar ist und realisiert wird.
3. Dass der Dynamische Speicher nachher häufig auch als Heap bezeichnet wird, darf natürlich erwähnt werden, ist aber IMHO von großer Nebensächlichkeit. Und dieser Heap sollte nicht als Datenstruktur aufgefassr werden.
4. Der Abstraktionsvorgang, der mit der Dynamischen Speicherzuordnung vollzogen wurde und der essenziell auf der Existenz des Zeigers beruht, kommt im Artikel völlig unzureichend zur Geltung.
5. Den Dynamischen Speicher als "zusätzlichen Pufferspeicher" zu bezeichnen, ist m.E. eine Irreführung, denn es geht nicht darum, etwas abzupuffern, sondern um das Unterbringen wesentlicher Daten.
6. Statt "Speicherüberlauf" sollte man besser von "Speicherbereichsüberschreitung" oder "Speicherüberschreitung" sprechen. Begründung: Überlauf ist viel zu passiv formuliert. Auch "Pufferüberschreitung" wäre OK, da das Speicherstück, das man z.B. bei einer malloc()-Anforderung erhält, häufig halt als Puffer bezeichnet wird. Dagegen, dass "buffer overflow" sich als Schlagwort eingebürgert hat, ist natürlich nichts mehr zu machen.

--Nomen4Omen (Diskussion) 12:54, 24. Okt. 2012 (CEST)

das hört sich so umfangreich aber nicht unbedingt falsch an... aber es beruht im wesentlich wohl auf deiner persönlichen meinung... WP:Q? --Heimschützenzentrum (?) 13:30, 24. Okt. 2012 (CEST)

zu deinem eingriff:

1. „<ref>Aber selbst hier können zu viele Aufrufe oder Rekursionen den Speicher überschreiten.</ref>“: hast du den sinn des ref-tags verstanden? :)
2. hat java nich auch dynamischen Speicher? ganz ohne zeiger und malloc oder sowas?

mehr hab ich grad nich bemerkt... *zzzzzz* --Heimschützenzentrum (?) 23:52, 24. Okt. 2012 (CEST)

es war mir zu aufwändig das alles zu korrigieren... vllt wäre es besser, hier schritt für schritt konkrete änderungen zu diskutieren? --Heimschützenzentrum (?) 08:40, 25. Okt. 2012 (CEST)

Das klang ja zunächst wesentlich erfreulicher.

Nun gut, du kannst dir ja auch in aller Ruhe die von dir rausgeschmissene Version ansehen. Oder noch besser die von mir jetzt nachgereichte.

Ansonsten habe ich ja Einzelheiten im hiesigen Diskussionsabschnitt zur Sprache gebracht. Deinen Einwand, dass es sich um meine persönliche Meinung handele, finde ich nicht so treffend, weil

• vorher noch weniger Belege drin waren
• die hingestellten Aussagen "common sense" sind und sich quasi selbst erklären

Der eine Interwiki-Link entspricht genau dem Standard. Den anderen habe ich raus.

Aus deiner Reaktion entnehme ich, dass du den Artikel als den Deinen betrachtest. Ich habe aber wirklich viel ganz gut gefunden und übernommen und will dir den Artikel auch nicht wirklich wegnehmen.

Allerdings habe ich den Abschnitt:

"Die dynamische Speicherverwaltung bietet dem Anwendungsentwickler die Möglichkeit, die Verwendung des Speichers innerhalb der Anwendung selbst zu steuern. Dies ist insbesondere bei systemnahen Anwendungen, Echtzeitanwendungen oder mobilen Anwendungen von Bedeutung, da hier die nicht-funktionalen Anforderungen gegenüber dem Speicherbedarf beziehungsweise dem Antwortzeitverhalten normaler Anwendungen abweichen können. Durch die stetig wachsende Leistungsfähigkeit der Hardware tritt dieser Aspekt jedoch immer weiter in den Hintergrund."

erstmal raus, weil es teilweise schon (besser?) da steht oder ich die angeführten Gründe nicht nachvollziehen kann. Ich denke, dass die angesprochenen Programmierer (hoffentlich) besser mit der Kompliziertheit umgehen können (und müssen). --Nomen4Omen (Diskussion) 09:38, 25. Okt. 2012 (CEST)

bevor du hier und (noch schlimmer) im artikel deine privatmeinung über grundbegriffe verbreitest, solltest du dich ersteinmal mit den WP regeln vertraut machen... kennst du noch einen WP artikel mit :en: links? das soll nämlich nicht sein... WP:Interwiki#Inline-Link mal lesen... und auch beachten... meine restliche kritik bitte beachten (malloc, Zeiger hat mit dyn SV erstmal nix zu tun...)... zeitnah bitte (sonst petz ich's...)... danke... --Heimschützenzentrum (?) 12:11, 25. Okt. 2012 (CEST)

ach je! also stilistisch ist die änderung in großen teilen nich tragbar, z B: „speicher [...] festgelegt“, „unter der Decke“, ... ich halte den artikel nicht für „meinen“... aber ich hab wenig lust, mir neue formulierungen anzusehen, die schon von der eingangs erklärten absicht her nur unwesentlich besser sind... ist eben zeitverschwendung... wieso überhaupt „interpreter“ (in der einleitung)? auf deiner disk steht, dass du schonmal so komische änderung vollführt hast... findest du das witzig, alle aufzuscheuchen? :-) mach es bitte selbst wieder weg... allenfalls können wir hier satz für satz die angeblich nötigen änderungen diskutieren und _danach_ den konsens umsetzen... --Heimschützenzentrum (?) 12:23, 25. Okt. 2012 (CEST)

In Ermangelung eines Artikels über Speicherzuordnung/-allokation allgemein oder statisch, halte ich es für das Beste, erstmal diesen Artikel auszubauen. Falls sich dann Teile dazu eignen ein umfassenderen oder zweiten Artikel aufzumachen, kann das später geschehen.

Weiterhin schließe ich mich Benutzer:Homer Landskirty an, die Formulierung ist weder sprachlich präzise noch inhaltlich allgemein genug gehalten. Auch bin ich versucht, die zweite Hälfte des Abschnitts Speicherverwaltung, sowie große Teile des Abschnitts Unterstützung ... zu löschen, da sie falsch/irrelevant/nur ein Spezialfall sind. -- Plankton314 (Diskussion) 13:02, 25. Okt. 2012 (CEST)

ich möchte nochmal anregen, den artikel in den vorherigen zustand zurückzuversetzen, weil man jetzt ganz schwer erkennen kann, was eigentlich besonders überprüft werden muss... --Heimschützenzentrum (?) 15:55, 25. Okt. 2012 (CEST)

@Benutzer:Homer Landskirty: Ich verstehe: Du kannst nicht weitermachen, ohne dass der Artikel in den vorherigen Zustand zurückversetzt ist.

Ist das nicht eine ganz furchtbar einfache Sache ?

So dass du es selbst machen könntest ?

--Nomen4Omen (Diskussion) 09:03, 26. Okt. 2012 (CEST)

Ich halte solche Kommentare hier nicht für zielführend. Benutzer:Homer Landskirty hat sich an der Diskussion beteiligt, wollte sich jedoch nicht in die gemachten Bearbeitungen einmischen.

Vielleicht liest du dir mal WP:WQ durch.

Der Artikel war in seinem vorherigen Zustand auch nicht das gelbe vom Ei, darum halte ich es für sinnvoller den aktuellen Zustand weiterzuentwickeln. -- Plankton314 (Diskussion) 10:03, 26. Okt. 2012 (CEST)

mag ja sein, dass ich Neuem intuitiv skeptischer gegenüber stehe, aber das Alte wurde immerhin von etlichen Lesern für gut genug befunden (und das seit Jahren)... z. B. passt gleich das zweite Wort nicht zum Artikelnamen... *heul* ich sehe hier das alte Muster des user:Nomen4Omen, der wohl gerne irgendwelche komischen Artikelverschiebungen durchführt... sehe ich das nun richtig, dass user:Nomen4Omen für einen Revert ist, aber user:Plankton314 dagegen? --Heimschützenzentrum (?) 11:21, 26. Okt. 2012 (CEST)

Ja, mit der Einleitung bin ich jetzt auch nicht zufrieden. Okay, dann zurück auf den Ausgangszustand. Der Abschnitt "Implementierung" kann von mir aus erhalten bleiben. -- Plankton314 (Diskussion) 11:32, 26. Okt. 2012 (CEST)

*aufatme* :-) und was genau sollte jetzt anders? also welcher absatz soll durch welchen ersetzt werden? den begriff „Dynamischer Speicher“ finde ich jedenfalls gar nicht so schlimm... nur weil die en:WP es anders nennt, müssen wir es ja nicht auch tun... --Heimschützenzentrum (?) 12:34, 26. Okt. 2012 (CEST)

Übrigens, im IBM/360-Assembler gab es für diesen zweck schon vor 50 jahren die makros GETMAIN, FREEMAIN – völlig analog zu den heute bekannten und im artikel erwähnten malloc(), free(). Und es redete kein mensch vom ‚Heap‘. Es war auch kein ‚Speicherbereich‘, ‚aus dem‘ man das angefordert hat. Sondern es war erst dann speicher, nachdem man bei GETMAIN etwas zurückbekommen hat – der speicher wurde gewissermaßen durch GETMAIN „erzeugt“ (jedenfalls war das die sicht des programmierers).
Es war auch nicht ‚Pufferspeicher‘, was man haben wollte oder bekam, sondern es war ein zusammenhängendes stück speicher, das man im programm in felder frei einteilen („formatieren“, d.h. mit format, layout versehen) konnte. Das ist alles bei malloc(), free() heute noch genau dasselbe prinzip.
Die nützlichkeit dieses prinzips kommt im artikel recht wenig zur geltung. So könnte ein BASIC-programmierer sagen: ich kann doch riesige bereiche definieren; wozu brauche ich den ganzen mist und alle seine gefahren.
Insofern ist auch der vergleich mit dem ‚Stack‘ eher eine fehlspur, da dieser genauso fix reserviert ist wie anderer nicht dynamischer speicher.
Leider gibt das englische dynamic memory allocation das alles auch nicht her. Aber wir müssen keineswegs immer „schlechter-gleich“ sein. (nicht signierter Beitrag von 92.203.5.16 (Diskussion) 17:40, 8. Nov. 2012 (CET))

die sicht es programmierers beschreiben wir doch schon... warum sollte man den artikel auf die sicht des programmierers beschränken oder heute unübliche begriffe einführen? der abschnitt „Unterschied zum Stack“ beschreibt doch gerade die vorzüge... --Heimschützenzentrum (?) 08:50, 9. Nov. 2012 (CET)

Lemma nicht eindeutig

Unter 'dynamischem Speicher' verstehe ich und sehr viele andere ohne weiteren Kontext erst einmal Speicherchips, die regelmäßig einen Refreshzyklus erfordern. Mein Vorschlag wäre hier der Begriff 'dynamischer Prozessspeicherbereich', da es sich um den Speicherbereich handelt, den ein Prozess für dynamische Speicheranforderungen nutzen kann. Es gibt ja auch noch prozessübergreifenden Hauptspeicher (shared memory). Was wäre also ein möglichst präzises Lemma?--H3xc0d3r (Diskussion) 15:59, 25. Jan. 2017 (CET)