---

Hvis man ser bort fra container klasser hvad er så den store fidus ved
templates?
STL er, som jeg ser det, primært containere og objekter der opererer på
disse. Når jeg selv har skullet finde et argument for templates har det
generelt været til containers. Der må da være mere ved det end som så?

Jeg kan også se en anden anvendelse som kan anvendes når man skal arbejde på
objekter af forskellig type, som arver visse metoder fra en fælles klasse.
Man vil jo normalt anvende en pointer til parent klassen, så man kan
behandle alle objekterne som værende denne parent. Samme kan gøres med
templates uden at det kræves objekterne er i familie bare de implementerer
de funktioner templaten anvendes, men... hvor ofte er det relevant?

---

"Hans Jakobsen" <hjk@mail.tele.dk> wrote:
> Hvis man ser bort fra container klasser hvad er så den store fidus ved
> templates?

Det er nok ikke nemt at svare kort på.
En god, men ikke triviel gennemgang af hvor f.eks. klasser og nedarvning er
passende og hvor brugen af templates er passende i C++ kan findes i bogen
Multi-Paradigm DESIGN for C++
James O. Coplien
ISBN 0-201-82467-1

Bemærk at jeg _ikke_ mener at der er en modsætning mellem brugen af klasser
og nedarvning og brugen af templates, således at man enten bruger det ene
eller det andet.
Det kan nemt og kraftfuld kombineres på mange måder - men det er også
beskrevet i nævnte bog.

> STL er, som jeg ser det, primært containere og objekter der opererer på
> disse.

STL er containere, algoritmer og iteratorer typer.
Desuden er det et bibliotek med nogle nyskabende design, som man kan lære af
og bygge videre på.

> Når jeg selv har skullet finde et argument for templates har det
> generelt været til containers. Der må da være mere ved det end som så?

Ja.
F.eks. generisk programmering.
Man kan f.eks. lave en generel linær søgning, som det er gjort i
"std::find", hvor man beskriver algoritmen generelt uden at kende typen på
det der skal findes, når blot typen og iteratorerne opfylder nogle få,
veldefinerede krav.


>
> Jeg kan også se en anden anvendelse som kan anvendes når man skal arbejde
på
> objekter af forskellig type, som arver visse metoder fra en fælles klasse.
> Man vil jo normalt anvende en pointer til parent klassen, så man kan
> behandle alle objekterne som værende denne parent. Samme kan gøres med
> templates uden at det kræves objekterne er i familie bare de implementerer
> de funktioner templaten anvendes, men... hvor ofte er det relevant?

Ofte, hvis man anvender generisk programmering
Prøv at tænk over det. Er det rimeligt at to klasser arver fra samme
basisklasse, blot fordi de har den samme (eller nogenlunde) funktion, men
iøvrigt ikke har nogen sammenhæng ?

Skulle Runde Tårn og et tordenskrald arve fra samme klasse, blot fordi man
kan spørge hvor høje de er ?
Hvis de arver fra en fælles basisklasse kan man sammenligne dem, hvilket
ikke giver nogen mening.
Hvis de ikke arver fra en fælles basisklasse, kan man ikke (i et statisk
typet objekt orienteret sprog som C++, Java og C#) genbruge sammenlignings
funktionen uden noget i retningen af templates.

Venlig hilsen

Mogens Hansen

---

On Tue, 13 Jan 2004 21:14:39 +0100, Mogens Hansen wrote:

> Multi-Paradigm DESIGN for C++
> James O. Coplien

Det var satans så mange interessant klingende bogreferencer, du kan ryste
ud af ærmet (har lige bestilt den).

Hvis du nu skulle opremse en Top-8 over dine C++-relaterede bøger,
hvordan ville den så se ud? (Top-5 er for lidt, fordi nogle i gruppen
ofte nævnte bøger sikkert vil udgøre hovedparten.)

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote:
> On Tue, 13 Jan 2004 21:14:39 +0100, Mogens Hansen wrote:
>
> > Multi-Paradigm DESIGN for C++
> > James O. Coplien
>
> Det var satans så mange interessant klingende bogreferencer, du kan ryste
> ud af ærmet


Det er at priviligie at have adgang til gode bøger og læse dem.
Mit eksemplar af ovennævnte blev iøvrigt signeret af forfatteren den
11.september 2001, inden dagen blev historisk!

> (har lige bestilt den).

Glimrende.
Fortvivl ikke hvis du syntes den er svær at komme i gang med - det er ikke
ualmindeligt. Jeg startede med at gå sukkerkold på den, måtte lade den ligge
i et par måneder og vente så tilbage til den og læste den i een køre og
bagefter han Ph.d. om samme emne.
Det var krævende - men givtigt.

>
> Hvis du nu skulle opremse en Top-8 over dine C++-relaterede bøger,
> hvordan ville den så se ud? (Top-5 er for lidt, fordi nogle i gruppen
> ofte nævnte bøger sikkert vil udgøre hovedparten.)

Jeg kan prøve.

En god introduktion til C++, hvis man kender lidt til programmering i
forvejen eller har brugt C++ længe uden at bruge std::string, std::vector og
std::map tit:
Accelerated C++
Andrew Koenig, Barbara E. Moo
ISBN 0-201-70353-X

Den uungåelige og ultimative kilde til C++
The C++ Programming Language, Special Edition (alternativt Third Edition)
Bjarne Stroustrup
ISBN 0-201-70073-5 (Third: 0-201-88954-4)

Gode uddybende bøger om standard library - mindst een af følgende:
The C++ Standard Library, A Tutorial and Reference
Nicolai M. Josuttis
ISBN 0-201-37926-0

STL Tutorial and Reference Guide: C++ Programming with the Standard
Template Library , Second Edition
David R. Musser, Gillmer J. Derge, Atul Saini
ISBN 0-201-37923-6

Generic Programming and the STL: Using and Extending the C++ Standard
Template Library
Matthew H. Austern
ISBN 0-201-30956-4

Samlinger af gode råd om anvendelse af C++:
Effective C++, Second Edition
Scott Meyers
ISBN 0-201-92488-9

More Effective C++
Scott Meyers
ISBN 0-201-63371-X

Effective STL
Scott Meyers
ISBN 0-201-74962-9

Exceptional C++
Herb Sutter
ISBN 0-201-61562-2

More Exceptional C++
Herb Sutter
ISBN 0-201-70434-X

En komplet beskrivelse af templates i C++
C++ Templates, The Comple Guide
David Vandevoorde, Nicolai M. Josuttis
ISBN 0-201-73484-2
og en masse interesant anvendelse heraf:
Modern C++ Design
Andrei Alexandrescu
ISBN 0-201-70431-5
(ikke kun templates, men væsentlige design overvejelser generelt)
Multi-Paradigm DESIGN for C++
James O. Coplien
ISBN 0-201-82467-1

Hvordan designer man effektivt _store_ projekter i C++:
Large-Scale C++ Software Design
John Lakos
ISBN 0-201-63362-0

Nå - det blev til mere end 8
Desuden er der jo naturligvis bøger om specielle områder, som f.eks.
netværksprogrammering, og mere generelle emner som design patterns etc.

Men kig iøvrigt på boganmeldelserne på www.accu.org.

Venlig hilsen

Mogens Hansen

---

On Tue, 13 Jan 2004 19:59:34 +0100, Hans Jakobsen wrote:

> Når jeg selv har skullet finde et argument for templates har det
> generelt været til containers. Der må da være mere ved det end som så?

Det kan fx. også bruges til at overflødiggøre nogle runtime checks.

Jeg prøver med et eksempel, der riskerer at forvirre mere end det
illustrerer (og måske endda er skrup-forkert; matrix-regning er ikke min
stærkeste side):

Det antages at en klasse i stil med følgende haves:

template <typename Scalar,std::size_t ROWS,std::size_t int COLS>
class matrix {
....
};

Lad os da sige, at der er defineret en krydsprodukt-operator (*). Denne
operator kan nu slippe for runtime at skulle kontrollere, om
matrix-dimensionerne passer, hvis operatoren er defineret i stil med

template<
typename LeftScalar,
typename RightScalar,
std::size_t L_ROWS,
std::size_t COMMON,
std::size_t R_COLS,
> matrix<LeftScalar,L_ROWS,R_COLS> operator*(
const matrix<LeftScalar,L_ROWS,COMMON>&,
const matrix<RightScalar,COMMON,R_ROWS>&
) {
....
}

Nu kan man fx. instatiere to matricer:

matrix<double,4,2> m1;
matrix<double,4,2> m2;
....

- Og uden at runtime checks er nødvendige, vil følgende allerede
ved kompilering blive afvist:

matrix<double,4,2> res=m1*m2;

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

> Jeg prøver med et eksempel, der riskerer at forvirre mere end det
> illustrerer (og måske endda er skrup-forkert; matrix-regning er ikke min
> stærkeste side):
>
> Det antages at en klasse i stil med følgende haves:
>
> template <typename Scalar,std::size_t ROWS,std::size_t int COLS>
> class matrix {
> ...
> };
>
> Lad os da sige, at der er defineret en krydsprodukt-operator (*). Denne
> operator kan nu slippe for runtime at skulle kontrollere, om
> matrix-dimensionerne passer, hvis operatoren er defineret i stil med
>
> template<
> typename LeftScalar,
> typename RightScalar,
> std::size_t L_ROWS,
> std::size_t COMMON,
> std::size_t R_COLS,
> > matrix<LeftScalar,L_ROWS,R_COLS> operator*(
> const matrix<LeftScalar,L_ROWS,COMMON>&,
> const matrix<RightScalar,COMMON,R_ROWS>& <-- her menes selvfølgelig R_COLS
> ) {
> ...
> }
>
> Nu kan man fx. instatiere to matricer:
>
> matrix<double,4,2> m1;
> matrix<double,4,2> m2;
> ...
>
> - Og uden at runtime checks er nødvendige, vil følgende allerede
> ved kompilering blive afvist:
>
> matrix<double,4,2> res=m1*m2;

Godt eksempel. Jeg vil lige pointere den sidste pointe :)
For at multiplicere to matricer med hinanden skal de have størrelserne
hhv X*Y og Y*Z - dvs den første matrix' højde skal være lig den anden
matrix' bredde. Dette sørger template't for. Det er umuligt at lave
fejl ved at multiplicere matricer som ikke kan multipliceres. [dette
kan selvfølgelig erstattes af en generel Matrix klasse og en masse
runtime checks]

Hvis man laver linked lists og gerne vil undgå en masse typecasting på
de returnerede data (med mulighed for fejl etc etc etc) er templates
også smarte. Du kan have en List<Adress> *adresses til adresser og en
List<Name> *names til navne - istedet for en generel List *adresses
hvor man så skulle typecaste data ned i Adress klassen når man hiver
dem ud.

---

Hans Jakobsen wrote:
> Hvis man ser bort fra container klasser hvad er så den store fidus ved
> templates?

Jeg tror den universelle fidus er metakode -- altså en evne til at
skrive generisk kode. Om det så er fidus nok til at anvende templates i
praksis er vel op til programmøren