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.

410 13. Templates<br />

Deklaration und die Def<strong>in</strong>ition von Templates vone<strong>in</strong>ander trennen kann und<br />

damit wieder unsere saubere Aufteilung <strong>in</strong> cpp und h Files erreichen kann.<br />

Wie man dabei vorgeht, wird <strong>in</strong> Abschnitt 13.7 noch genauer behandelt. Um<br />

den Blick auf das Wesentliche nicht zu verlieren, begnügen wir uns derzeit<br />

e<strong>in</strong>fach e<strong>in</strong>mal mit dieser etwas unschönen Organisation des Source Codes<br />

und lassen Templates vollständig <strong>in</strong>klusive Def<strong>in</strong>itionen im Header stehen.<br />

Nur so als kle<strong>in</strong>es Gedankenexperiment möchte ich hier noch folgende<br />

Frage <strong>in</strong> den Raum stellen: Was muss man tun, wenn man bereits im generischen<br />

Typ selbst verankern will, dass es sich um e<strong>in</strong>en Po<strong>in</strong>ter handelt? Als<br />

Parameter will man also nicht mehr<br />

const ElementType *element<br />

stehen haben, sondern z.B.<br />

const ElementTypePtr element<br />

Nun, im Pr<strong>in</strong>zip ist das ganz e<strong>in</strong>fach, wie die folgende Modifikation beweist<br />

(f<strong>in</strong>d_max_template_function_v2.h):<br />

1 // f<strong>in</strong>d max template function v2 . h − a s l i g h t change o f the f i r s t<br />

2 // implementation that i n c l u d e s the po<strong>in</strong>ter <strong>in</strong> the g e n e r i c type<br />

3<br />

4 #ifndef f i n d m a x t e m p l a t e f u n c t i o n h<br />

5 #def<strong>in</strong>e f i n d m a x t e m p l a t e f u n c t i o n h<br />

6<br />

7 #<strong>in</strong>clude ” u s e r t y p e s . h”<br />

8<br />

9 template u<strong>in</strong>t32 f<strong>in</strong>dMax (<br />

10 const ElementTypePtr elements , u<strong>in</strong>t32 num elements )<br />

11 {<br />

12 u<strong>in</strong>t32 current max = 0;<br />

13<br />

14 for ( u<strong>in</strong>t32 <strong>in</strong>dex = 0 ; <strong>in</strong>dex < num elements ; <strong>in</strong>dex++)<br />

15 {<br />

16 i f ( elements [ <strong>in</strong>dex ] > elements [ current max ] )<br />

17 current max = <strong>in</strong>dex ;<br />

18 }<br />

19 return ( current max ) ;<br />

20 }<br />

21<br />

22 #endif // f i n d m a x t e m p l a t e f u n c t i o n h<br />

Es wurde ganz e<strong>in</strong>fach der Name des generischen Parameters geändert, um<br />

Entwicklern, die Zeile 9 lesen, zu signalisieren, dass hier e<strong>in</strong> Po<strong>in</strong>ter erwartet<br />

wird. Weiters wurde beim ersten Parameter <strong>in</strong> Zeile 10 der * weggelassen,<br />

denn wir wollen ja, dass der Po<strong>in</strong>ter bereits Teil des generischen Parameters<br />

ist. Beim Auflösen kommt der Compiler ja schon automatisch darauf, dass<br />

mit ElementTypePtr z.B. <strong>in</strong> unserem Testprogramm entweder e<strong>in</strong> <strong>in</strong>t32 *<br />

oder eben e<strong>in</strong> double * geme<strong>in</strong>t ist, denn nur so kann er e<strong>in</strong> korrektes Match<strong>in</strong>g<br />

vornehmen.<br />

Das Testprogramm dazu hat sich bis auf das Inkludieren des modifizierten<br />

Headers gar nicht verändert. Deshalb möchte ich es auch hier nicht abdrucken.<br />

Es ist unter dem Namen f<strong>in</strong>d_max_test_v2.cpp auf der beiliegenden

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!