30.06.2013 Aufrufe

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

6.2 Po<strong>in</strong>ter 121<br />

bei unseren kle<strong>in</strong>en Testprogrammen der Speicher nicht ausgehen wird<br />

und lassen diesen Aspekt außer Acht.<br />

C Programmierern, die noch malloc gewohnt s<strong>in</strong>d, das die Größe <strong>in</strong><br />

Bytes gesagt bekommen muss, wird new zu Beg<strong>in</strong>n etwas ungewohnt<br />

vorkommen. Aber damit lernt man schnell zu leben, weil es doch e<strong>in</strong>e<br />

deutliche Verbesserung darstellt.<br />

Vorsicht Falle: Der new Operator ist <strong>in</strong> se<strong>in</strong>er Standard-Implementation<br />

so def<strong>in</strong>iert, dass e<strong>in</strong>e implizite Initialisierung des Speichers nicht<br />

garantiert ist! Das bedeutet, dass unbed<strong>in</strong>gt immer e<strong>in</strong>e explizite Zuweisung<br />

e<strong>in</strong>es Wertes erfolgen muss, da man es sonst mit irgende<strong>in</strong>em<br />

zufälligen Wert zu tun hat. Dies erfolgt z.B. für unseren <strong>in</strong> Zeile 16<br />

angeforderten Speicher für e<strong>in</strong>en <strong>in</strong>t32 <strong>in</strong> Zeile 17.<br />

Vorsicht Falle: Entwicklern, die im Umgang mit Po<strong>in</strong>tern ungeübt<br />

s<strong>in</strong>d, passiert es leider nur zu gerne, dass sie den dereference Operator,<br />

also den *, bei e<strong>in</strong>er Zuweisung e<strong>in</strong>es Wertes vergessen. Schreibt man<br />

z.B. <strong>in</strong> Zeile 17 das Statement dyn_var = 10;, so führt das zu e<strong>in</strong>em<br />

Compilerfehler. Diese Zuweisung würde nämlich bedeuten, dass man<br />

dem Po<strong>in</strong>ter dyn_var die Adresse 10 zuweisen will und das ist nicht<br />

zulässig.<br />

Zeile 20: Speicher, den man dynamisch mittels new anfordert, bleibt so lange<br />

für das Programm reserviert, bis er explizit wieder freigegeben wird (ich<br />

klammere hier e<strong>in</strong>e mögliche Implementation von C ++ mittels Garbage-<br />

Collector bewusst aus). Das bedeutet, dass man sich unbed<strong>in</strong>gt immer<br />

selbst darum kümmern muss, dass alle angeforderten Speicherblöcke dem<br />

System auch wieder durch Aufruf des delete Operators zurückgegeben<br />

werden. In unserem Fall bewirkt der Aufruf delete dyn_var das Freigeben<br />

des zuvor angeforderten <strong>in</strong>t32.<br />

Vorsicht Falle: Der Operator delete ist so def<strong>in</strong>iert, dass er natürlich<br />

nur Speicher wieder freigeben kann, der mit new angefordert wurde. Daher<br />

darf man delete nur mit e<strong>in</strong>em Base-Po<strong>in</strong>ter aufrufen, den man von<br />

new bekommen hat. Ruft man delete mit irgende<strong>in</strong>em anderen als e<strong>in</strong>em<br />

von new erhaltenen Base-Po<strong>in</strong>ter auf, so endet dieser Aufruf mit<br />

e<strong>in</strong>er Segmentation Violation.<br />

Vorsicht Falle: Niemals darf man den Base-Po<strong>in</strong>ter e<strong>in</strong>es Speicherblocks<br />

verlieren! Sollte dies passieren, so kann der Speicher nicht mehr<br />

freigegeben werden (womit sollte man denn delete aufrufen?) und damit<br />

wächst das Programm beständig! Wie bereits erwähnt: Speicher, der mit<br />

new angefordert wird, wird vom System nicht automatisch wieder freigegeben!<br />

Vergisst man e<strong>in</strong> delete, so gammelt der betreffende Block bis

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!