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.

5. Funktionen 93<br />

paar für den Exponenten reserviert, fehlen also bei der Mantisse und<br />

bewirken, je nach Zahl, e<strong>in</strong> Abschneiden des <strong>in</strong>t64 Wertes.<br />

Zum Glück kann man als Entwickler e<strong>in</strong>greifen und dem Compiler <strong>in</strong> se<strong>in</strong>er<br />

dunklen Stunde der Unentschlossenheit mitteilen, was man eigentlich<br />

will. Dies geschieht <strong>in</strong> Zeile 29, denn durch den expliziten Cast hat es der<br />

Compiler wieder mit e<strong>in</strong>em <strong>in</strong>t32 als Parameter zu tun. Was er damit<br />

anfangen soll, weiß er und setzt den Aufruf der <strong>in</strong> Zeile 10 deklarierten<br />

Funktion e<strong>in</strong>.<br />

Zeile 31: Auch diese Zeile treibt den Compiler zur Verzweiflung, denn er steht<br />

vor der Wahl, e<strong>in</strong>en double entweder zu e<strong>in</strong>em float oder zu e<strong>in</strong>em<br />

<strong>in</strong>t32 verkommen zu lassen, um e<strong>in</strong>e der Funktionen deklariert <strong>in</strong> den<br />

Zeilen 10 und 11 aufrufen zu können. Beides ist natürlich aus bekannten<br />

Gründen nicht problemlos, also beschwert sich der Compiler lieber und<br />

überlässt den Entwicklern die Entscheidung. Die Lösung des Problems<br />

ist, wie anzunehmen war, wieder e<strong>in</strong> expliziter Cast. In Zeile 33 sieht<br />

man den entsprechenden korrigierten Aufruf.<br />

Alle Aussagen, die ich hier über den Aufruf bestimmter Funktionen aus e<strong>in</strong>er<br />

Reihe von Varianten getroffen habe, lassen sich leicht verifizieren, <strong>in</strong>dem man<br />

die beiden problematischen Zeilen auskommentiert, die zum Ambiguitätsproblem<br />

führen und danach das Programm übersetzt. Der Output, der dann<br />

generiert wird, sieht folgendermaßen aus:<br />

show ( <strong>in</strong>t32 , bool ) c a l l e d<br />

20<br />

show ( f l o a t , bool ) c a l l e d<br />

12.5<br />

show ( <strong>in</strong>t32 , bool ) c a l l e d<br />

10<br />

show ( double ) c a l l e d<br />

12.5<br />

show ( <strong>in</strong>t32 , bool ) c a l l e d<br />

10<br />

show ( f l o a t , bool ) c a l l e d<br />

12.5<br />

Das Regelwerk, nach dem der Compiler versucht, den bestmöglichen Funktionsaufruf<br />

aus e<strong>in</strong>er Reihe von Alternativen zu f<strong>in</strong>den, ist relativ komplex.<br />

Jedoch ist es so ausgelegt, dass immer die Variante e<strong>in</strong>gesetzt wird, bei der<br />

ke<strong>in</strong>e gefährlichen Umwandlungen auftreten. Kann der Compiler ke<strong>in</strong>e solche<br />

Variante f<strong>in</strong>den und steht vor e<strong>in</strong>er Reihe von Alternativen, die alle nicht<br />

optimal s<strong>in</strong>d, so muss man als Entwickler durch e<strong>in</strong>en expliziten Cast e<strong>in</strong>greifen.<br />

Vorsicht Falle: Gerade C ++ Neul<strong>in</strong>ge neigen oft dazu, Overload<strong>in</strong>g zu<br />

übertreiben und für viele verschiedene Datentypen, die eigentlich kompatibel<br />

wären, eigene Funktionen zu schreiben, anstatt sich auf die Kompatibilität<br />

zu verlassen. Dies kann schnell zu Überraschungen führen, wenn man sich<br />

zu wenig Gedanken über die Auswirkungen macht. Deshalb möchte ich hier<br />

drei Tipps geben:

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!