Forum: C-Programmieren

Hallo,

ist es schlechter Programmierstil, wenn man bei der Stringbearbeitung einen max. Speicher vial malloc() anfordert, statt in einem Loop mehrere realloc() zu verwenden?
also:
malloc(genug Speicher) Loop bis fertig Bearbeite String End Loop
statt:

malloc(bekannte Anzahl Bytes)
Loop bis fertig
Bearbeite String
realloc(bekannte Anzahl weitere Bytes)
End Loop

Die genaue Anzahl Bytes ist erst während der Ausführung bekannt. Die max. Grösse des Speicherbedarfs weiss man aber schon vorher.

Besten Dank

 

Sorry falsch formatiert:

malloc(genug Speicher)
Loop bis fertig
Bearbeite String
End Loop

statt:

malloc(bekannte Anzahl Bytes)
Loop bis fertig
Bearbeite String
realloc(bekannte Anzahl weitere Bytes)
End Loop

 

Gute Frage!

Wenn Du die Größe des benötigten Speichers vor dem Loop schon kennst, ist es ratsam, diesen auch in einem Rutsch anzufordern.

Wenn Du erst in der Schleife die Größe ermitteln kannst, verwendest Du realloc(). Geschickte Implementationen fordern hierbei das jeweils Doppelte der vorherigen Größe an. Also sagen wir mal, wir fangen mit 1024 Bytes an; wenn die voll sind, werden 2*1024=2048 Bytes angefordert; wenn die voll sind, werden 2*2048=4096 Bytes angefordert usw.

Bei einer letztendlichen Größe von n Bytes reduziert diese Methode die benötigten Aufrufe von realloc() auf maximal log(n) (oder genauer: auf log(n) - log(startwert)).

Und der Vollständigkeit halber: schrumpft der Speicherbedarf zur Laufzeit auch wieder, so reduziert man den angeforderten Speicher um die Hälfte, wenn er nur noch zu einem Viertel belegt ist. Haben wir also 4096 Bytes Speicher reserviert und der Verbrauch fällt unter 1024, so reduzieren wir auf 4096/2=2048 Bytes. Fällt der Verbrauch dann unter 512, so reduzieren wir auf 1024 usw.

Gruss,
Philip

--
The C Programming Quiz - bitte Fragen einreichen :)

 

Zitat:

Wenn Du die Größe des benötigten Speichers vor dem Loop schon kennst, ist es ratsam, diesen auch in einem Rutsch anzufordern.
.
.
Bei einer letztendlichen Größe von n Bytes reduziert diese Methode die benötigten Aufrufe von realloc() auf maximal log(n) (oder genauer: auf log(n) - log(startwert)).
.
.

Danke für die Antwort! Ich lese zwei Aussagen heraus:

Zitat:

So wenig realloc() wie möglich
Und wenn - Storagegrösse binär gestalten (512, 1024.....)

Die Frage entstand, da man oft abenteuerliche Konstrukte sieht, was dann unter anderem zu

Zitat:
*** glibc detected *** ./input: realloc(): invalid next size:

Fehlern führen kann, für die es keinen wirklichen Grund gibt. Im Netz sind dann genau so abenteuerliche Antworten zu finden...

Kann man mein obiges Statement so stehen lassen?

Besten Dank

 

Zitat:

Kann man mein obiges Statement so stehen lassen?

Nicht generell, aber oft. Es kommt auch noch auf ein paar andere Sachen an:
Wenn es sich um ein paar Gigabyte handelt geht man anders damit um, als mit ein paar Kilobyte.
Im Kernelspace wird oft bytegenau gearbeitet.
Die Zielplattform spielt eine Rolle. Ein kleines mobiles Device, ein i386, oder ein echtes System mit Pfeffer unterm Hintern.

Kleines Beispiel, ich hab hier nen Mittelformatscanner, der Bilddateien von annähernd 1GB erzeugt. Die Software ist nur für i386 erhältlich, das Ding macht aber auch Mehrfachabtastungen etc. Hier haben dies falsch gemacht, das Dingen schmiert stumpf ab, wenns an die Grenzen von i386 gerät und ich musste die Kiste erst aufbohren.

Wie man mit den Speicheranforderungen umgeht ist echt ne Sache für sich. Man sollte immer in Betracht ziehen, dass physikalische Grenzen, mit denen wir heute zu schaffen haben nächstes Jahr eventuell kalter Kaffee sind.

Bis denne

Martin

--
0xC0FFEE