MultiAllocateMemory

[Kaeru Gaman]

entschuldige, Nico, es ging mir nur um eine Hintergrund-Frage.

wenn du sagst, dass Memblocks, die kurz hintereinander allociert wurden,
alle freigegeben werden, wenn ein nächstes Alloc fehlschlägt,
dann frage ich: wo ist die grenze?
wieviel früher muss eine Mem allociert werden,
um nicht bei einem fehlschlag eines erneuten Alloc freigegeben zu werden?

dabei geht es mir weniger um deine Routine (sorry)
sondern um die verfahrensweise des Standard-Alloc von PB.

> Dein Bild ist nicht weg...
trifft das zu, wenn ich mit standard-alloc arbeite?

1000 pardon. das ist eine grundsatz-frage zu standard-funktionen.
vielleicht habe ich zu wenig hintergrundwissen in bezug auf PB-befehle,
aber kaum zu wenig hintergrundwissen in bezug auf allgemeine Speicherverwaltung.

[NicTheQuick]

Du stiftest hier wohl gern Verwirrung, was?

Es werden keine allokierten Speicherbereiche wieder einfach so freigegeben,
wenn sie einmal allokiert sind. Das musst du schon selbst machen. Von
alleine wird nichts einfach so wieder freigegeben.

Wenn ein AllocateMemory() fehl schlägt, dann wurde der Speicher nicht allokiert und kann somit nicht benutzt werden. Logisch. Aber es werden keine
anderen Speicherbereiche wieder freigegeben, damit ein neuer allokiert
werden kann. Das wäre ja Blödsinn.

[Kaeru Gaman]

nein, verdori.
ich will nur wissen, was abgeht.

warum zum geflügelten nackthals bringst du dann ne routine raus,
wenn es eh banane is, wann welches Mem wo wie allocated wurde?

wenn ich beim normalen pennermäßigen geschlafenen allocate nen fehler erwarten muss,
dann wüsste ich auch gerne, wo wann wie!

und wenn nich, dann hab ich dich mißverstanden, und sorry.

barn, ich kann doch hier nich so ne nummer durchziehn. wo is mein produzent? feuer ma den regisseur.

[NicTheQuick]

Tut mir Leid. Ich kann es dir nicht besser erklären.

Ich weiß nur, dass sie für manche Sachen praktisch sein könnte.

@all außer Kaeru:
Hilfe!

[#NULL]

warum zum geflügelten nackthals

es geht nicht darum zusätzliche sicherheitsfeatures bereitzustellen. es geht lediglich darum, schreibarbeit zu sparen. nämlich die schreibarbeit, alle speicher wieder freizugeben, die man für eine geplante arbeit benötigt hätte - eine arbeit die man aber nicht ausführen konnte, weil einer der dafür benötigten speicherblöcke z.b. nicht alloziiert werden konnte.

dass du die zuvor alloziierten blöcke nicht mehr benutzten wirst, hat nichts direkt mit irgendeinem alloc-fehlschlag zu tun. du könntest sie auch benutzen, aber du willst es nicht, weil du für das was du vorhattest auch jene bräuchtest, die du eben nicht erhalten konntest (weil z.b. der speicher voll ist).
..also gibst du sie wieder frei.. und das kannst du mit NTQ's dingsta in einem rutsch erledigen.

vielleicht versteh ich dich ja auch nur nich
[in diesem thread spukt es]

[HeX0R]

Wieso sagt eigentlich keiner was zu meiner Methode ?
So daneben, oder hatte ich einfach das Pech des 9. Posters ?

[Proton]

>>>Hexor: Wieso sagt eigentlich keiner was zu meiner Methode ?

Deine Methode ist auf jeden Fall der Methode von NicTheQuick vorzuziehen.
Sie erlaubt auch noch andere Dinge wie z.B. übergreifende Pointer in
Schleifen usw.

Nur hilft sie leider auch nicht gegen meine momentane Erkältung und Fieber

[Karl]

@HeXOr:

Finde ich so auch besser und übersichtlicher so, wenn zur Kompilierzeit schon bekannt ist, was ich so alles brauche. Die andere Methode ist eher für dynamische Geschichten interessant - ich glaube fast, dass es darum geht.

Gruß Karl

[NicTheQuick]

@HeX0R:
Genau, es ging um dynamische Speicherblöcke, die man im Nachhinein
nochmal in der Größe ändern kann. So ist es bei mir nämlich.

Für statische Zwecke ist eine Methode natürlich die einfachere.