templates in c++

[Alarmnummer]

Ik ben wat aan het experimenteren met c++ en ik ben tegen een probleem aangelopen. Als ik een headerfile heb met daarin een geparametriseerde class definitie (template) in een cc file heb ik de definitie staan, dan struikelt de compiler daarover.

De oplossing voor dit probleem is om 'export' voor de template declaratie te zetten. Helaas pikt mijn g++ compiler dit niet. Ik heb het internet een hele tijd zitten zoeken, maar nergens heb ik een bevredigend antwoord gevonden. Sommigen die plaatsen alles maar in de header , sommigen die plaatsen definitie + declaratie in de source en importeren dat in de header

Er moet toch een betere oplossing zijn dan dit geklungel? En minder templates gebruiken is geen optie. Het zou achterlijk zijn om een zeer handige feature niet te gebruiken omdat ze het niet voor elkaar krijgen om het goed te implementeren.

[Verwijderd]

Ik plaats template definities in de headers, maar heb daar geen enkel probleem mee.. (sterker nog, af en toe vind ik het juist wel makkelijk dat ik geen aparte declaratie meer nodig heb).

[Alarmnummer]

Het is juist de bedoeling van een header file en een 'source' file, dat declaratie en definitie van elkaar gescheiden worden. Ik vind het du een erg slechte zaak om te gaan implementeren in een header file (weet eerlijk gezegd ook niet zo goed wat ik moet vinden van eenvoudige getters.

[Verwijderd]

Ach, ik heb het file/translation-unit model van c/c++ altijd al crap gevonden, dus over een beetje verkrachting ervan maak ik me niet zo druk .

[Glimi]

Tja, mijn gebruikelijke methode was altijd in de .h file de declaraties schrijven en dan in de .cpp de implementatie.
Onderin de .h file stond dan

code:

#include "ClassName.cpp"

Noem het ranzig, maar dat is imho wat ik van het hele class/header geblaat van C++ vindt Werken deed het iig altijd wel

edit:
Geen venster open laten staan en dan nog gaan reply'en aap!

[Soultaker]

Het idee van de scheiding tussen header en source files, is dat je de source files kan compileren naar binary object files en deze met uitsluitend de header files kunt gebruiken. Aangezien het voor het gebruik van templates vereist is dat de broncode van de template beschikbaar moet zijn, kan deze dus logischerwijs niet in een header file geplaatst worden. Om dezelfde reden moeten inline methoden en default arguments ook in de header files gespecificeerd worden.

De scheiding in source en header files heeft dus maar weinig te maken met een scheiding tusen interface en implementatie. Je moet header files meer zien als de informatie die andere applicaties nodig hebben, terwijl de inhoud van de source files onbelangrijk is voor de werking van de code.

Als je toch erg graag je interfaces gescheiden wilt specificeren, houdt niemand je tegen om aparte header files met uitsluitend interface informatie te maken en hiervan te erven in de daadwerkelijke implementatieklassen, die elders gedefinieerd worden. Uiteraard moet een applicatie dan nog steeds de implementatieklassen instantieren, maar dat kan ook niet anders (je kunt immers ook geen Java of IDL interface instantieren).

[Soultaker]

Glimi schreef op 31 oktober 2002 @ 20:09:
Tja, mijn gebruikelijke methode was altijd in de .h file de declaraties schrijven en dan in de .cpp de implementatie.
Onderin de .h file stond dan

code:

#include "ClassName.cpp"

Ik noem dat ranzig en bovendien werkt het niet. Je kunt dan niet meer je sources apart compileren en linken, want dan krijg je allerlei clashes met dubbel gedefinieerde variabelen en functies. Bovendien ontkom je er in C++ niet aan om inline functies in je header file te schrijven.

[Verwijderd]

#include "ClassName.cpp"

AAAAARGH. . dit is vloeken !!!!!!!!!

[Glimi]

Soultaker schreef op 31 oktober 2002 @ 20:41:
[...]
Ik noem dat ranzig en bovendien werkt het niet. Je kunt dan niet meer je sources apart compileren en linken, want dan krijg je allerlei clashes met dubbel gedefinieerde variabelen en functies. Bovendien ontkom je er in C++ niet aan om inline functies in je header file te schrijven.

Nuttig om te weten. Die 3 blauwe maandagen dat ik voor school C++ heb moeten programmeren hebben ze deze manier in m'n hoofd laten stampen. Ik heb nooit geleerd/geweten waarom er een aparte header declaratie gemaakt moest worden voor een functie, anders dan implementatie en interface gescheiden.

Iig bedankt voor de info
* Glimi streept "Data structures and other Objects Using C++" door van zijn nuttige boekenlijst

[Alarmnummer]

Maar wat is dan wel de gebruikelijke aanpak? Toch de implementaties in de headerfiles gooien?

[farlane]

Yup. Bekijk de STL maar es, die doet dat ook op die manier...

[Verwijderd]

In het boek "Data Structures and other Objects Using C++" van Main en Savitch wordt de implementatie file ook onderaan de header file geinclude. Dus ik neem aan dat dit de meest gebruikelijke manier is, aangezien ze de code zoveel mogelijk op de 'stl manier' opbouwen.

[Glimi]

Verwijderd schreef op 31 oktober 2002 @ 23:28:
In het boek "Data Structures and other Objects Using C++" van Main en Savitch wordt de implementatie file ook onderaan de header file geinclude. Dus ik neem aan dat dit de meest gebruikelijke manier is, aangezien ze de code zoveel mogelijk op de 'stl manier' opbouwen.

* Glimi streept "Data structures and other Objects Using C++" door van zijn nuttige boekenlijst

[Verwijderd]

Glimi schreef op 31 oktober 2002 @ 23:33:
[...]


[...]

Streep de stl dan ook maar door

[Verwijderd]

Ik denk dat er een misverstand in het spel is. Soultaker vindt het includen van de implementatie onderaan de header niet goed omdat hij niet door heeft dat het om implementaties van templates gaat.

Voorbeeldje:

max.h:

C++:

template <class T> inline T max(const T&, const T&);

#include "max.cpp"

max.cpp:

C++:

template <class T> inline T max(const T& a, const T& b)
{
    return b > a ? b : a;
}

Dit doet geen van de dingen die Soultaker beweert en scheidt de implementatie van de declaraties, dus het kan gewoon.

[Alarmnummer]

Maar kunnen jullie nu 1 goed voorbeeld geven?

[Verwijderd]

"Goed" voorbeeld

dumbarray.h

C++:

#ifndef DUMBARRAY_H
#define DUMBARRAY_H
.
extern "C++" {
.
template <class T, unsigned DIM> class DumbArray {
public:
    class Exception {};
.
    DumbArray();
    const T& operator [] (int idx) const throw (Exception);
    T& operator [] (int idx) throw (Exception);
.
private:
    T _vector[DIM];
};
.
#include "dumbarray.cpp"
.
} // extern "C++"
.
#endif /* DUMBARRAY_H */

dumbarray.cpp:

C++:

#include <algorithm>
.
template <class T, unsigned DIM> DumbArray<T, DIM>::DumbArray()
{
    std::fill(_vector, _vector + DIM, T(0));
}
.
template <class T, unsigned DIM>
const T& DumbArray<T, DIM>::operator [] (int i) const
throw (DumbArray<T, DIM>::Exception)
{
    if(0 > i || i >= static_cast<int>(DIM)) throw Exception();
    return _vector[i];
}
.
template <class T, unsigned DIM>
T& DumbArray<T, DIM>::operator [] (int i)
throw (DumbArray<T, DIM>::Exception)
{
    if(0 > i || i >= static_cast<int>(DIM)) throw Exception();
    return _vector[i];
}

edit:
Toevoeging:

Doe dit dus alleen met templated en inlined functions/methods, include nooit een .cpp file waar functions of methods in staan die niet templated of inlined zijn.

[Verwijderd]

hmmm... Dit probleem heb ik ook al eens gehad...
Je ontkomt er volgens mij gewoon niet aan om de implementatie te includen... Ofwel via de #include abc.cpp in je header ofwel door de implementatie direct in je header te proppen.
Niet mooi, maar het zei zo. C++ is imho ook niet echt een taal die ervoor gemaakt is om mooi te zijn, maar om als werkpaard te dienen

[Soultaker]

Verwijderd schreef op 01 november 2002 @ 00:01:
Ik denk dat er een misverstand in het spel is. Soultaker vindt het includen van de implementatie onderaan de header niet goed omdat hij niet door heeft dat het om implementaties van templates gaat.

Jawel; je mag van mij ook prima implementaties in je headers zetten. Mijn punt was dat source files (.c, .cc, .cpp, choose your pick) onafhankelijk naar object files gecompileerd moeten kunnen worden. In elke normale build-omgeving gebeurt dat ook automatisch.

Je mag natuurlijk best je header implementatie in een ander bestand stoppen, maar dat is dan wel een header file (.h of .hh) want op zichzelf is 'ie niet te compileren.

Als ik jou voorbeeld probeer te compileren, gaat het mooi fout. Type maar eens "make dumbarray.o" in.

Ik schrijf trouwens al m'n templates gewoon in de header. Ik zie niet in waarom daar geen code in zou mogen staan. Netjes juist; alle template code in de header.

[MSalters]

Er is een expliciete regel voor templates, die zoveel zegt als dat ze in headers mogen worden gedefinieerd. Das is gedaan juist om te kunnen werken totdat export beschikbaar is.

[Alarmnummer]

Ik vind persoonlijk een geparametriseerde class niet anders dan een niet geparametriseerde class. Ik zou daarom dus ook geen verschil ertussen willen maken en dan inconsistent zijn met de locatie van de definities. Ik vind een header een beschrijving van een class (de declaratie), en in de source staat de definitie en dat geldt ook voor templates.

Ik vind het jammer dat die export niet functioneert, maar ik zal het voorlopig maar in die header plaatsen.

[curry684]

Alarmnummer schreef op 31 oktober 2002 @ 21:16:
Maar wat is dan wel de gebruikelijke aanpak? Toch de implementaties in de headerfiles gooien?

Ik zet template implementaties in *.inl (inline) files tussen de cpp's. Zo houdt je de implementatie toch uit de headers maar kun je ze alsnog stiekem los includen.

Je ontkomt er niet aan, de template-implementatie moet per definitie bekend zijn op het moment van instantiatie.

[Alarmnummer]

Hmmz.. ik ben het niet met je eens dat dit per definitie hoeft te gelden. Het komt denk ik door de aanpak van templates in c++. Ik wil het dus zelfs gooien op een te kort koming van de compiler en dat kan ik zelf ondersteunen door het feit dat er speciaal hiervoor het export keyword voor de template kan komen te staan om aan te geven dat de implementatie ergens anders staat.

Maar die '*.inl' vind ik eerlijk gezegd ook nog niet eens zo`n gekke oplossing. Ik vind het juist erg handig dat je een scheiding hebt van implementatie en declaratie. Dat samenklonteren vind ik bv aan java ook zo irritant.

En maak je dan ook nog een lege source file aan die niets anders doet dan die volledig geimplementeerde class includen?

[curry684]

Ik werk zelf met root-headers voor lib-secties, bijv. fictief als volgt:

C++:

// ----------------------------------------------------------------------
// Root include for collection classes
//
// Filename:  MyLibCollections.hpp
// Author:    Curry
// Date:      01-11-02
// ----------------------------------------------------------------------

#ifndef MyLibCollectionsH
#define MyLibCollectionsH

// ----------------------------------------------------------------------
// Main collection includes
// ----------------------------------------------------------------------

#include "MyLibArrays.hpp"
#include "MyLibLists.hpp"
...

// ----------------------------------------------------------------------
// Inline files
// ----------------------------------------------------------------------

#include "MyLibCol_Array.inl"
#include "MyLibCol_LinkedList.inl"
#include "MyLibCol_SortedList.inl"
...

// ----------------------------------------------------------------------
#endif     // MyLibCollectionsH

Waarbij de template definitie voor de linked list en de sorted list in MyLibLists.hpp staan en de template implementaties in de genoemde inlines. Eventuele normale classes staan gewoon in hun eigen cpp's.

In Visual Studio ziet een project er dan als volgt uit:

code:

+ MyCollectionLib.lib
--+ Header files
  -- MyLibCollections.hpp
  -- MyLibArrays.hpp
  -- MyLibLists.hpp
--+ Lists
  -- MyLibCol_BaseList.cpp
  -- MyLibCol_LinkedList.inl
...

[Verwijderd]

Soultaker schreef op 01 november 2002 @ 03:21:
Jawel; je mag van mij ook prima implementaties in je headers zetten. Mijn punt was dat source files (.c, .cc, .cpp, choose your pick) onafhankelijk naar object files gecompileerd moeten kunnen worden. In elke normale build-omgeving gebeurt dat ook automatisch.

Je mag natuurlijk best je header implementatie in een ander bestand stoppen, maar dat is dan wel een header file (.h of .hh) want op zichzelf is 'ie niet te compileren.

Als ik jou voorbeeld probeer te compileren, gaat het mooi fout. Type maar eens "make dumbarray.o" in.

Christus, dit vind ik wel echt insectenliefde. Dus omdat het wel degelijk een implementatie is, maar geen code genereert mag het niet in een .cc file? En dat je een make target probeert te bouwen dat er niet is, is geen fout zeker? Je zou er wel een andere extensie voor kunnen bedenken, zoals in curry's .inl voorstel, maar dat is geen default c++ bestandsextensie en breekt een hoop buildtools.

Ik schrijf trouwens al m'n templates gewoon in de header. Ik zie niet in waarom daar geen code in zou mogen staan. Netjes juist; alle template code in de header.

Omdat je implementaties en declaraties wilt scheiden, net als in andere talen. Als je dan gedwongen wordt implementaties in headers te zetten is dat niet netjes.

Bottom line: als STL-implementators het ook doen, zal het weinig kwaad kunnen.

[.oisyn]

Verwijderd schreef op 01 november 2002 @ 13:01:
[...]

Christus, dit vind ik wel echt insectenliefde. Dus omdat het wel degelijk een implementatie is, maar geen code genereert mag het niet in een .cc file? En dat je een make target probeert te bouwen dat er niet is, is geen fout zeker? Je zou er wel een andere extensie voor kunnen bedenken, zoals in curry's .inl voorstel, maar dat is geen default c++ bestandsextensie en breekt een hoop buildtools.

ik #include zelf meestal (als de implementatie te groot is en ik het daarom lelijk vind in de normale .h) iets met dezelfde naam, maar met _impl.h erachter

Ik vind het gewoon... vreemd... om .cpp files in een include dir te hebben (en ik ben het met soultaker eens dat een .cpp file apart te compileren moet zijn)

[curry684]

Verwijderd schreef op 01 november 2002 @ 13:01:
Je zou er wel een andere extensie voor kunnen bedenken, zoals in curry's .inl voorstel, maar dat is geen default c++ bestandsextensie en breekt een hoop buildtools.

.inl is een standaard extensie in Borland en MS compilers, dus da's redelijk standaard wereldwijd. Daarnaast heb je denk ik het concept niet helemaal door, want een buildtool KAN hier niet op breken... kijk dat een tool het niet slikt als ik een *.bier file probeer te compileren kan ik inkomen, maar als er in een cpp direct of indirect de volgende regel staat:

C++:

#include "veel.bier"

Dan hoort die tool daar gewoon de file veel.bier inline te expanden. Ergo iedere tool dient foutloos met .inl files te kunnen werken zolang je ze maar als inline file gebruikt (zie mijn post 2 schermen hierboven).

[Verwijderd]

Ik ben net begonnen met C++ en heb ongeveer hetzelfde probleem als in dit topic ter sprake komt. Ik gebruik alleen geen templates e.d., dus ik vroeg mij af of hier hetzelfde geldt

test1.h

C++:

#ifndef TEST1_H
#define TEST1_H

int test_func(int i);

#endif

test1.cpp

C++:

#include <iostream>
#include "test1.h"

int test_func(int i) {
    cout << "Argument is: " << i << endl;
    return i;
}

test.cpp

C++:

#include <iostream>
#include "test1.h"

int main() {

    test_func(4);
    return 0;
}

als ik nu g++ test.cpp doe, krijg ik de volgende foutmelding:

code:

/tmp/ccbThVmr.o: In function `main':
/tmp/ccbThVmr.o(.text+0xc): undefined reference to `test_func(int)'
collect2: ld returned 1 exit status

Begrijp ik het nu goed dat ik dit moet oplossen door onderaan test1.h de regel

C++:

#include "test1.cpp"

toe te voegen? En moet ik regel 2 van test1.cpp wel laten staan?

[Alarmnummer]

je vergeet een bestand te compileren:
g++ test.cpp test1.cpp

[Verwijderd]

.oisyn schreef op 01 november 2002 @ 13:11:
Ik vind het gewoon... vreemd... om .cpp files in een include dir te hebben (en ik ben het met soultaker eens dat een .cpp file apart te compileren moet zijn)

En verschillende STL-implementators zijn het daar dus niet mee eens. Nergens in de specs staat dat een .cpp file tot een .o file te compilen moet zijn.

curry684 schreef op 01 november 2002 @ 14:02:
.inl is een standaard extensie in Borland en MS compilers, dus da's redelijk standaard wereldwijd.

Aha, dus omdat twee fabrikanten op een platform een extensie gebruiken is het een standaard? Of is het de gewone wintel arrogantie?

Daarnaast heb je denk ik het concept niet helemaal door, want een buildtool KAN hier niet op breken... kijk dat een tool het niet slikt als ik een *.bier file probeer te compileren kan ik inkomen

Verschillende code management tools pikken geen C++ files die een nonstandaard extensie hebben, je kunt ze niet includen in een project. Noch in een header, noch in een sourcefile. Je kunt dan wel handmatig buiten de toolset om toch andere files gaan zitten includen, maar dan kun je de toolset niet meer gebruiken; ergo: breekt toolsets.

[Verwijderd]

Alarmnummer schreef op 01 november 2002 @ 14:30:
je vergeet een bestand te compileren:
g++ test.cpp test1.cpp

Okee.. dan werkt het inderdaad wel.. kan je me misschien ook vertellen hoe ik dit in een makefile gooi?

[ Voor 0% gewijzigd door Verwijderd op 01-11-2002 14:41 . Reden: typo ]

[Alarmnummer]

Verwijderd schreef op 01 november 2002 @ 14:40:
[...]

Okee.. dan werkt het inderdaad wel.. kan je me misschien ook vertellen hoe ik dit in een makefile gooi?

Ik ben ook nog maar net begonnen, en op dit moment werk ik gewoon nog vanaf de command line om de compiler in ieder geval een beetje beter door te krijgen. Ik ga als ik meer sourcefiles heb, wel over op een makefile.

[Verwijderd]

Okee, bedankt in ieder geval

[.oisyn]

[nohtml]

Verwijderd schreef op 01 november 2002 @ 14:31:
En verschillende STL-implementators zijn het daar dus niet mee eens.

sorry, maar dat boeit mij dus weer geen enkele spreekwoordelijke flikker
Ik vind het gewoon raar om .cpp files in mijn include dir te hebben staan, dat geeft alleen maar verwarring als je er een tijd later weer eens naar kijkt ("heej, wat doet die cpp file daar :?"). De aparte implementatie header constructie die ik gebruik bevalt me veel beter.

Nergens in de specs staat dat een .cpp file tot een .o file te compilen moet zijn.

Dat zeg ik ook helemaal niet, maar zoals ik al zei: dat zorgt voor verwarring. Het gebruik van geinclude cpp is imho een vieze code style, en als verschillende STL implementators dat gebruiken, dan vindt ik dat die implementators vies coden... simple as that (nou is de implementatie meestal toch niet leesbaar gecode, dus wat codestyle betreft heb ik niet zo'n hoge dunk van die implementators)

Maar goed, dit loopt uit op een discussie over verschillende meningen die toch nergens over gaat

[Verwijderd]

Waarom templates trouwens niet gewoon zonder extensie? gewoon:

C++:

#include <vector>
#include "FooTemplate"

en die file include vervolgens een _FooTemplate.hpp headerfile met de interface-spec van de template, en daaropvolgend de _FooTemplate.cpp sourcefile met de template-implementatie. Zo doe ik het En zo doet ook de STL het en papa Bjarne. Dan weet je ook veel beter wat je leest in je code:

C++:

#include "Foo1" // hier gaat het om een template 
#include "Foo2.hpp" // hier gaat het om een headerfile van een class
#include "Foo3.inl" // hier gaat het om een inline class-implementatie.

Enneh, .inl is wel een standaard, maar dan voor inline definities, dus:
.hpp/.hh/.hxx: interface
.cpp/.cc/.cxx: implementatie
.inl/.icc/.ixx: inline implementatie, wordt geinclude vanuit de headerfile, tenzij het wenselijker is (.i.v.m. debuggen bijvoorbeeld) om niet te inline-nen, dan vanuit de sourcefile.

Dit wordt ook ondersteunt door code-editors onder linux bijvoorbeeld, want daar gaat het alleen maar om als je het hebt over "code management tools" die de extensie "inl" niet zouden herkennen. De Compiler zal er niet snel van wakkerliggen, want zowel een template als een header/inline class-implementatie moet/kan/mag niet tot een object worden gecompileerd, alleen indirect via elke sourcefile die de file (viavia) include-t. (En welke IDE staat het dan wel niet toe? Kun je niet eens Readme.txt, Changelog e.d. bij het project inzetten )

[MSalters]

Tsja, uiteindelijk is het probleem dat een template definitie de definitie is van een oneindige aantal classes. Dat past gewoon slecht in een .o file.
Pas als je de eindige hoeveelheid plekken hebt waar dat template gebruikt wordt kun je het aantal template instantiaties bepalen - maar als je die plekken hebt ( in template_gebruiker.o via template_gebruiker.cpp ) dan kun je daar ook de template instantiaties kwijt.

[curry684]

Verwijderd schreef op 01 november 2002 @ 14:31:
Aha, dus omdat twee fabrikanten op een platform een extensie gebruiken is het een standaard? Of is het de gewone wintel arrogantie?

Mmmm hier hebben we het al vaker over gehad, en ja ik blijf erbij als meer dan de helft van de markt (of in dit geval zelfs 90+% van de markt) het gebruikt het een standaard is. Dat definieert volgens ieder woordenboek op deze wereld een standaard: dat de ruime meerderheid van de mensen waarop het van toepassing is het gebruikt. Of de commissie van wijze mannen van de STDL het daarmee eens zijn is me worst.

De CD is de standaard geluidsdrager.
GSM is de standaard voor mobiele telefoons.
Een muismat is het standaard-ding om onder je muis te leggen.
De standaard verblijfplaats voor mensen om 4 uur 's nachts is het bed.
De standaard om bier te drinken is uit glas.
Windows is het standaard OS.

Need I go on?

Met al deze standaarden kun jij het oneens zijn, maar ze zijn er wel. Probleem is dat jij een standaard ziet als iets dat gedefinieerd wordt door wijze mannen waarna het volk gedwee volgt, en dat ik een standaard zie als iets dat door het volk gebruikt wordt.

[Alarmnummer]

Pfff.. volgens mij mogen die mensen echt wel eens een cursus compiler bouw gaan volgen. Jezus, wat een kutfoutmeldingen, en waarom is die c++ compiler zo godsellendig dom. Forward declaraties: in welk jaar leven we?? Er schijnt al zo iets te bestaan als een multipass parser, dus waarom zo ouderwets? Waarom dat zielige geklungel met geparametriseerde classes??? Dat is bij andere talen toch echt wel een beetje geavanceerder.


zo.. ff stoom afgeblazen. Misschien dat ik er maar eens een echte compiler bij pak ipv dat ouderwetse ding.

[curry684]

C++ is uit 1979 en backwards compatible met een taal uit omstreeks 1970. Daarom is het een taal met bepaalde features die 'niet meer van deze tijd' zijn.

[Alarmnummer]

Hmmzz.. tijd om dit beest uit zijn leiden te verlossen, en een nieuwe object georienteerde c taal op de markt te brengen die gewoon naar native code compileerd, maar waarin verscheidene nieuwe technieken in de compiler zijn gebouwd. (en dan bedoel ik geen c#, maar echt een verbeterde versie van c++)

Ik moest even mijn stoom kwijt. Met c++ heb je inderdaad een enorm stuk controle tot je beschikking en een aantal features die kunnen een hele applicatie aan gort helpen. Maar daarom moet je ze ook met verstand gebruiken. Ik heb dus totaal geen problemen met pointers/references/preprocessor etc want dit zijn gewoon onmisbare/extreem handige dingen. Maar andere dingen zijn ronduit ouderwets.

Je kan het vergelijken met een forumle 1 wagen met houten tandwielen

[Verwijderd]

geeft niet, als jij nog een C++ compiler gebruikt die nog altijd eerst C-code maakt, mag je wel stoom afblazen
Maar noem het liever een zakmes met voor jouw veel te veel functionaliteiten, waar jij een envelop mee wilt openen. Polymorphisme/rtti/exceptionhandling/enz. zijn echt niet ouderwets o.i.d.
Of noem het een formule 1 wagen met twee sturen, voor voor en achter... Misschien hoef jij niet zulke scherpe bochten te maken, maar een ander wel en voor diegene is dat stuur wel handig. Denk trouwens eerder dat C++ als jeep bedoelt is... Niet voor de rauwe snelheid, maar voor brede inzetbaarheid

[Verwijderd]

curry684 schreef op 01 november 2002 @ 15:38:
Met al deze standaarden kun jij het oneens zijn, maar ze zijn er wel. Probleem is dat jij een standaard ziet als iets dat gedefinieerd wordt door wijze mannen waarna het volk gedwee volgt, en dat ik een standaard zie als iets dat door het volk gebruikt wordt.

Het verschil is natuurlijk dat dit informele standaarden zijn, terwijl je spreekt over een formele programmeertaal. Een formele taal heeft formele standaards nodig, geen informele. Need I go on?

Alarmnummer schreef op 01 november 2002 @ 16:08:
Pfff.. volgens mij mogen die mensen echt wel eens een cursus compiler bouw gaan volgen. Jezus, wat een kutfoutmeldingen, en waarom is die c++ compiler zo godsellendig dom. Forward declaraties: in welk jaar leven we?? Er schijnt al zo iets te bestaan als een multipass parser, dus waarom zo ouderwets? Waarom dat zielige geklungel met geparametriseerde classes??? Dat is bij andere talen toch echt wel een beetje geavanceerder.

Forward declaraties zijn niet toegestaan om practische redenen: het compileren zou veel langer duren met multipass parsing. Ben je wel eens nagegaan hoeveel er eigenlijk geinclude wordt in een normale apllicatie? Realiseer je je hoeveel langer het zou duren als deze ontzettende bulk aan headerfiles niet een maar 2x geparsed zou worden?

Bovendien heb je daar nog het punt van backwards compatibility, C++ kan het zich als produktietaal niet permitteren bij elke nieuwe versie de compatibiliteit met bestaande sourcecode te breken.

[MSalters]

Alarmnummer schreef op 01 november 2002 @ 16:08:
Waarom dat zielige geklungel met geparametriseerde classes??? Dat is bij andere talen toch echt wel een beetje geavanceerder.

Nou niet dus. C++ is de eerste mainstream taal waarin een Turing-complete type-safe compile-time taal zit. Dat verklaart natuurlijk wel waarom het verre van perfect is.

Voorbeeldje (van Bjarne):

code:

template <typename T>
void foo( T, int ) { }
template <typename T>
void foo( int,T ) { }

Opdracht: lever de specialisatie van het eerste template voor T==int.

Daar had dus niemand aan gedacht

[Alarmnummer]

MSalters schreef op 01 november 2002 @ 17:00:
[...]

Nou niet dus. C++ is de eerste mainstream taal waarin een Turing-complete type-safe compile-time taal zit.

Maar het begin wel oud te worden. Kijk maar eens naar bv haskell, clean of naar java icm gj of een andere geparametriseerde type extensie voor java. En verder is Nice ook een goed voorbeeld hoe het ook zeer elegant kan. Ik ben het dus niet met je eens dat c++ nou bepaald modern is op het gebied van template afhandeling. Het werkt gewoon klungelig.

Voorbeeldje (van Bjarne):

code:

template <typename T>
void foo( T, int ) { }
template <typename T>
void foo( int,T ) { }

Opdracht: lever de specialisatie van het eerste template voor T==int.

Daar had dus niemand aan gedacht

Voor zover ik weet zijn geparametriseerde types voor het eerst toegepast in ML. En verder wordt in functionele talen vaak ook gebruik gemaakt van type inference, en daardoor krijg je een enorm complex typesysteem. Op het moment dat je dus expliciet zelf alle types moet aangeven, neemt de complexitteit van de typechecker enorm af.

En verder vind ik dit maar een eigenaardig voorbeeld. Er kan namelijk een ambiguiteit ontstaan. Misschien zou bij de compilatie van deze templates een foutmelding opgeworpen moeten worden zodat deze ambiguiteit wordt uitgesloten.

En als je dat niet wilt doen, dan begin je te gaan naar dispatchen op functie argumenten, en dat is eerlijk gezegd ook tot in den treure uitgemolken. Ik kan dus niet veel vernieuwends ontdekken aan c++ Het is een mengsel van elementen uit verschillende talen (waar absoluut niets mis mee is).

[Orphix]

Ik implementeer mijn templates gewoon altijd in de headerfiles. Meestal zijn de methods/functies toch dermate klein dat ik me er niet aan erger.

En bovendien ... wat maakt het uit of implementatie/specificatie gescheiden is? Je wilt toch niet zeggen dat je geen documentatie bij je programmatuur levert?!!

[Alarmnummer]

Als ik inzicht in een class wil krijgen, dan hoef ik geen definities te zien. Dit is vooral handig bij gebruik van een class, want tenslotte ben je dan niet geinteresseerd hoe die class aan de binnenkant in elkaar steekt. (encapsulation).

En verder zijn mijn functies niet dermate klein dat ik ze in de header kan zetten. Ik maak vaak gebruik van geparametriseerde polymorfisme, dus ik heb te veel code voor in de header.

Ik zou dan net zogoed alles in headers kunnen plaatsen

[Orphix]

Alarmnummer schreef op 01 november 2002 @ 17:27:
Als ik inzicht in een class wil krijgen, dan hoef ik geen definities te zien. Dit is vooral handig bij gebruik van een class, want tenslotte ben je dan niet geinteresseerd hoe die class aan de binnenkant in elkaar steekt. (encapsulation).

En verder zijn mijn functies niet dermate klein, want ik maak vaak gebruik van geparametriseerde polymorfisme, dus ik heb veel code dat gebruik maakt van templates.

Dat begrijp ik, maar een klassen overzicht in een paar HTML pagina's vind ik nog beter. De structuur in mijn projecten kan ik bovendien ook mooi via mijn IDE bekijken.

[Alarmnummer]

curry684 schreef op 01 november 2002 @ 16:18:
C++ is uit 1979 en backwards compatible met een taal uit omstreeks 1970. Daarom is het een taal met bepaalde features die 'niet meer van deze tijd' zijn.

http://www.plaguedesigns.com/c.html => 1983

en templates ed zijn er nog veel later ingekomen:
http://www.vandevoorde.co...es/templates_history.html 1995

[MSalters]

Alarmnummer schreef op 01 november 2002 @ 17:36:
en templates ed zijn er nog veel later ingekomen:
http://www.vandevoorde.co...es/templates_history.html 1995

Nee, dat is de datum waarop David Vandevoorde begon met het boek "C++ Templates". Templates komen uit de ARM (maar toen waren ze nog "experimenteel")

[MSalters]

Alarmnummer schreef op 01 november 2002 @ 17:15:
[...]

Maar het begin wel oud te worden. Kijk maar eens naar bv haskell, clean of naar java icm gj of een andere geparametriseerde type extensie voor java. En verder is Nice ook een goed voorbeeld hoe het ook zeer elegant kan.

Tsja, om heel eerlijk te zijn staan nice en gj dus op het nivo van templates in de ARM. Experimenteel; nog geen support voor non-type template parameters of expliciete specialisatie, geen type-mapped constants ( vb: je kunt een C++ template maken zodat uses_heap<int>::value==false; uses_heap<std::string>::value==true, etc. ). Ook is operator overloading niet altijd aanwezig (essentieel voor templates - is het nou a.equals(b), Equals(a,b), equal_to(a,b) of gewoon altijd a==b)

Ik ben het dus niet met je eens dat c++ nou bepaald modern is op het gebied van template afhandeling. Het werkt gewoon klungelig.

Het is zeker niet de meest optmiale syntax, dat is bekend. Mijn voorbeeld toont dat ook aan: Twee templates die op zich niet ambigu zijn, maar het is onmogelijk ze te onderscheiden op het moment dat een van de twee gespecialiseerd zou moeten worden.
Overigens is het een klein beetje een strikvraag - bonuspunten voor wie dat ziet.

[Soultaker]

MSalters schreef op 01 november 2002 @ 17:00:
Voorbeeldje (van Bjarne):

code:

template <typename T>
void foo( T, int ) { }
template <typename T>
void foo( int,T ) { }

Opdracht: lever de specialisatie van het eerste template voor T==int.

Vraagje tussendoor: wat bedoel je met de 'specialisatie' van die template functie? Voor zover ik nu zie, doen beide foo-functies niets (met WELK type ze ook geparametriseerd worden).

edit:
Even de quote erbij gezet, anders is hier geen touw aan vast te knopen.

[Alarmnummer]

MSalters schreef op 01 november 2002 @ 20:02:
[...]

Tsja, om heel eerlijk te zijn staan nice en gj dus op het nivo van templates in de ARM. Experimenteel; nog geen support voor non-type template parameters of expliciete specialisatie, geen type-mapped constants ( vb: je kunt een C++ template maken zodat uses_heap<int>::value==false; uses_heap<std::string>::value==true, etc. ).

Hmmzz.. dan moet ik me hier nog maar even in gaan verdiepen *is gek op krachtige typesystemen*

Ook is operator overloading niet altijd aanwezig (essentieel voor templates - is het nou a.equals(b), Equals(a,b), equal_to(a,b) of gewoon altijd a==b)

Ik heb tot nu toe nooit gewerkt met operator overloading (althans niet in een imperatieve taal). Dus ik heb ook niet het gevoel dat ik iets mis en ben het daarom niet met je eens dat het 'verplicht' is. De functie syntax is inderdaad meestal naadje, maarja.. ik kan er nog mee leven.. Ik neem aan dat ik over een tijdje niet meer zonder wil werken. (Trouwens Nice heeft wel operator overloading)

Het is zeker niet de meest optmiale syntax, dat is bekend. Mijn voorbeeld toont dat ook aan: Twee templates die op zich niet ambigu zijn, maar het is onmogelijk ze te onderscheiden op het moment dat een van de twee gespecialiseerd zou moeten worden.
Overigens is het een klein beetje een strikvraag - bonuspunten voor wie dat ziet.

Hmmzz.. ik zie niet wat er te zien zou moeten zijn Ik neem aan dat de 1e er dan maar uitgepikt gaat worden?

[Alarmnummer]

Soultaker schreef op 01 november 2002 @ 20:15:
Vraagje tussendoor: wat bedoel je met de 'specialisatie' van die template functie? Voor zover ik nu zie, doen beide foo-functies niets (met WELK type ze ook geparametriseerd worden).

Ik neem aan dat hij parametrisatie van een type bedoelt.

[Soultaker]

Alarmnummer schreef op 01 november 2002 @ 20:19:
Ik neem aan dat hij parametrisatie van een type bedoelt.

Oh; dat had ik overwogen, maar ik zag het probleem niet. Nu wel, trouwens; je instantieert ze natuurlijk beiden 'tegelijk'.

Maar wat is nu precies het strik-element erin? (Behalve dat 't kut is dat 't niet werkt met ints?).

[Alarmnummer]

Soultaker schreef op 01 november 2002 @ 20:23:
Maar wat is nu precies het strik-element erin? (Behalve dat 't kut is dat 't niet werkt met ints?).

Dat er misschien geen strik inzit

Heeft c++ trouwens ook voor het volgende probleem een oplossing?

Java:

interface List<A>{
   <B extends A> void addAll(List<B> l);
}

Op deze manier kan je ieder subtype van een lijst meegeven, dus arraylist,vector ed. Maar je kan ook een lijst (of subtype) van ieder subtype van A meegeven.

[MSalters]

Soultaker schreef op 01 november 2002 @ 20:15:
[...]


Vraagje tussendoor: wat bedoel je met de 'specialisatie' van die template functie? Voor zover ik nu zie, doen beide foo-functies niets (met WELK type ze ook geparametriseerd worden).
[/edit]

Dat ze niets doen is eigenlijk niet van belang. Het idee is dat je een expliciete specialisatie van de eerste met T==int wilt kunnen schrijven (die dus niet leeg zal zijn), maar dat je door (onvoorziene) syntax problemen niet kunt aangeven dat

code:

template < >
void foo<int, int>( int a,int b) { MyCout << b-a; }

een specialisatie is van het eerste template.

[MSalters]

Alarmnummer schreef op 01 november 2002 @ 20:17:
Ik heb tot nu toe nooit gewerkt met operator overloading (althans niet in een imperatieve taal). Dus ik heb ook niet het gevoel dat ik iets mis en ben het daarom niet met je eens dat het 'verplicht' is. De functie syntax is inderdaad meestal naadje, maarja.. ik kan er nog mee leven.. Ik neem aan dat ik over een tijdje niet meer zonder wil werken. (Trouwens Nice heeft wel operator overloading)

Probeer eens een generieke functie te schijven die drie argumenten van ongespecificeerd type T accepteert, en true retourneert als er precies twee gelijk aan elkaar zijn en een niet.

A ) In C++, met gebruik van de overloaded operator==(T,T)

B ) In een taal zonder operator overloading.

[MSalters]

Soultaker schreef op 01 november 2002 @ 20:23:
Maar wat is nu precies het strik-element erin? (Behalve dat 't kut is dat 't niet werkt met ints?).

Dat het in de praktijk oplosbaar is door een non-template foo(int, int) te schrijven. non-templates worden verkozen in function overloading boven template instantiaties met dezelfde parameters. Het gaat pas echt fout bij class templates.

[Alarmnummer]

Als het argument een object is, dan kan je gewoon de equals methode gebruiken (functie is wel overloaded). Als het primitieve types zijn, dan gaat het wat lastiger worden.

[MSalters]

Alarmnummer schreef op 01 november 2002 @ 20:29:
Heeft c++ trouwens ook voor het volgende probleem een oplossing?

Java:

interface List<A>{
   <B extends A> void addAll(List<B> l);
}

Op deze manier kan je ieder subtype van een lijst meegeven, dus arraylist,vector ed. Maar je kan ook een lijst (of subtype) van ieder subtype van A meegeven.

Class template member templates

C++:

template <typename A>
class List {
    template < typename Iterator >
    void addAll( Iterator begin, Iterator end ) { ... }
}

Is al standaard voor de bestaande STL containers. Het werkt, omdat een gederefencde List<B>::iterator een B object is, en dat kan (met slicing) aan een A object worden toegekend.

Als je A* en B* gebruikt, dan je kun je op dezelfde manier een B* aan een A* assignen, zonder slicing.
Vrijwel alle smartpointers kun je ook downcasten op deze manier; in de meeste smartpointer implementaties checkt de compiler of de types de goede relatie hebben.

Dus vanuit de STL gezien hoef je er geen moeite voor te doen.

[Alarmnummer]

In mijn voorbeeld kan je alleen die A van een waarde voorzien, en die B kan je dus niet zelf opgeven. Die is puur voor de typechecker. Hoeveel typeparameters moet je in jouw voorbeeld meegeven? Volgens mij moet je er 2 opgeven, en niet 1.

In mijn geval is het dus niet mogelijk om bij A = persoon die lijst te voorzien van een lijst van auto`s. In jouw geval zou dat denk ik wel mogelijk zijn, als je voor B Iterator<Auto> opgeeft.

[.oisyn]

Alarmnummer schreef op 02 november 2002 @ 19:17:
In mijn geval is het dus niet mogelijk om bij A = persoon die lijst te voorzien van een lijst van auto`s. In jouw geval zou dat denk ik wel mogelijk zijn, als je voor B Iterator<Auto> opgeeft.

het is mogelijk, je krijgt alleen errors omdat een Auto niet te assignen is aan een A (tenzij er natuurlijk een casting operator gedefinieerd is). Hoewel ik deze feature idd wel mis, is het toch vrij nutteloos... het zorgt alleen voor betere compiler errors

[Soultaker]

Ik vind het wel jammer dat die functionaliteit mist; het is in theorie natuurlijk een krachtige uitbreiding. Ik kan me trouwens niet herinneren er in de praktijk ooit last van te hebben gehad dat 'ie ontbreekt; collection types kun je in ieder geval prima type-safe initialiseren met een iterator (zoals MSAlters al zei, trouwens).

[Verwijderd]

.oisyn schreef op 02 november 2002 @ 23:41:
Hoewel ik deze feature idd wel mis, is het toch vrij nutteloos... het zorgt alleen voor betere compiler errors

Die betere compiler errors kun je bereiken met de Boost Concept Check Library en Boost static assertions. Ik ben het overigens eens met Stroustrup in D&E 15.4, waarin hij constraints on template arguments features in de taal zelf afwijst.

[MSalters]

Verwijderd schreef op 03 november 2002 @ 00:32:
[...]
Die betere compiler errors kun je bereiken met de Boost Concept Check Library en Boost static assertions. Ik ben het overigens eens met Stroustrup in D&E 15.4, waarin hij constraints on template arguments features in de taal zelf afwijst.

Verassing misschien, maar zijn tegenwoordig wijst hij ze niet meer (volledig, unconditioneel) af. D&E is alweer fors oud.

Aan de andere kant is er nog steeds consensus dat als een goede compiler en een library iets kunnen oplossen, dat de core language zich er buiten moet houden. De gweone assert is ook geen core language, tenslotte, maar een library macro.

[Verwijderd]

MSalters schreef op 03 november 2002 @ 22:11:
[...]

Verassing misschien, maar zijn tegenwoordig wijst hij ze niet meer (volledig, unconditioneel) af. D&E is alweer fors oud.

Ik ben dan heel benieuwd wat hij in gedachten heeft, heb je daar meer informatie of links over?

[Alarmnummer]

Verwijderd schreef op 03 november 2002 @ 00:32:
[...]
Die betere compiler errors kun je bereiken met de Boost Concept Check Library en Boost static assertions. Ik ben het overigens eens met Stroustrup in D&E 15.4, waarin hij constraints on template arguments features in de taal zelf afwijst.

Constaints op typeparameters is wel een beetje klassiek. Ik zou wel eens willen waarom hij dat niet nodig zou vinden (misschien onkunde?)

[edit]
het zou ook kunnen omdat de templates eigelijk niets anders is dan code generatie (in tegenstelling tot andere talen), en daar heb je in mindere mate een 'zwaarder' oo ontwerp voor nodig omdat je het er gewoon in kan genereren en dan krijg je de compile foutmeldingen wel.

[Verwijderd]

Alarmnummer schreef op 03 november 2002 @ 22:32:
[...]

Constaints op typeparameters is wel een beetje klassiek. Ik zou wel eens willen waarom hij dat niet nodig zou vinden (misschien onkunde?)

Hij wijst constraints op typeparameters niet af, maar wil er in D&E geen language feature voor hebben.

[Alarmnummer]

Verwijderd schreef op 03 november 2002 @ 22:35:
[...]

Hij wijst constraints op typeparameters niet af, maar wil er in D&E geen language feature voor hebben.

Hmmmzz.. ik loop al op gj af te geven omdat ze op sommige plekken niet genoeg mogelijkheden geven om extra voorwaarden op te stellen. Ik zou dus zien op alle plekken waar het nuttig is, dat daar ruimte is om constraints, of andere handige type constructies te gaan plaatsen om een mooi object ontwerp te krijgen.

En wat is D&E?

[Verwijderd]

Alarmnummer schreef op 03 november 2002 @ 22:37:
[...]


Hmmmzz.. ik loop al op gj af te geven omdat ze op sommige plekken niet genoeg mogelijkheden geven om extra voorwaarden op te stellen.

Wat is "gj" ?

Ik zou dus zien op alle plekken waar het nuttig is, dat daar ruimte is om constraints, of andere handige type constructies te gaan plaatsen om een mooi object ontwerp te krijgen.

En wat is D&E?

The Design & Evolution of C++

[Alarmnummer]

Verwijderd schreef op 03 november 2002 @ 22:40:
[...]

Wat is "gj" ?

Dat is een taal extensie voor java waarmee je geparametriseerde types kan maken. Dit gaat onderdeel uittmaken van jdk1.5, maar je kan het nu ook al gebruiken.

The Design & Evolution of C++

Ok

[MSalters]

Alarmnummer schreef op 03 november 2002 @ 22:32:
Constaints op typeparameters is wel een beetje klassiek. Ik zou wel eens willen waarom hij dat niet nodig zou vinden (misschien onkunde?)

[edit]
het zou ook kunnen omdat de templates eigelijk niets anders is dan code generatie (in tegenstelling tot andere talen), en daar heb je in mindere mate een 'zwaarder' oo ontwerp voor nodig omdat je het er gewoon in kan genereren en dan krijg je de compile foutmeldingen wel.

Er zijn effectief al constraints mogelijk op template parameters; bv. via partiele specialisatie van een template. Andrei Alexandrescu heeft ook laten zien (in oa Modern C++ Design) dat je template specialisatie voor een heleboel constraints kunt gebruiken; Boost concept checks zijn misschien nog wel beter.

Wat ook een rol speelt is dat de ontwikkeling van error-checking techineken gelijke tred houdt met de onwikkeling van template libraries; er zijn te weinign mensen die behoefte hebben om een Core-language constraint-systeem te schrijven dat met de voorgestelde Library oplossingen concurreert.

Het laatste probleem is dat OO geen nuttige techniek is gebleken in de ontwikkeling van generieke libraries. Niet voor niets is Andrei Alexandrescu een verklaard tegenstander van member functies. (!)

[Alarmnummer]

MSalters schreef op 04 november 2002 @ 08:26:
[...]
Er zijn effectief al constraints mogelijk op template parameters; bv. via partiele specialisatie van een template. Andrei Alexandrescu heeft ook laten zien (in oa Modern C++ Design) dat je template specialisatie voor een heleboel constraints kunt gebruiken; Boost concept checks zijn misschien nog wel beter.

Wat bedoelt me specialisatie en partitiele specialisatie?

De 1e is de typeparameters van waarden voorzien, en de 2e is een aantal typeparameters van waarden te voorzien?

Het laatste probleem is dat OO geen nuttige techniek is gebleken in de ontwikkeling van generieke libraries.

En welk paradigma is dan beter geschikt hiervoor?

Niet voor niets is Andrei Alexandrescu een verklaard tegenstander van member functies. (!)

Hmmzz.. member functies zijn overgewardeerd. Member functies, zijn gewoon functies met een impliciet vermeld 1e argument (het object waarop je de methode aanroept) en verder heeft dit object beschikking over velden die gewoonlijk niet toegankelijk zijn.

Dit is eigelijk een beetje de klassieke aanpak voor member functies, maar er zijn ook allerlei nieuwe technieken bedacht zoals open objects. Hiermee is het dus mogelijk om buiten een class een functie te gaan declareren waarmee je dezelfde mogelijkheden hebt als een 'klassieke' methode en waar naast single dispatch vaak ook multidispatch aanwezig is (deze methoden heten dan ook wel multimethods).

Op het moment dat Andrei gaat zeggen dat de 'klassieke' methodes slecht zijn omdat ze gewoon harstikke ouderwets zijn, dan ben ik het 100% met hem eens, maar als hij een ander argument heeft om member functies af te keuren, dan zou ik die graag willen weten.

[MSalters]

Alarmnummer schreef op 04 november 2002 @ 09:07:
[...]

Wat bedoelt me specialisatie en partitiele specialisatie?

De 1e is de typeparameters van waarden voorzien, en de 2e is een aantal typeparameters van waarden te voorzien?

Nee, er zijn twee varianten van specialisatie: De eerste ("expliciete") is waarbij je aangeeft dat een variant van een template gebruikt moet worden indien een template geinstantieerd worrdt voor een enkel bijzonder type (bv alleen als T==int), de tweede variant is dat je een bepaalde specialisatie moet gebruiken als een template wordt geinstantieerd voor een groep types (bv T=pointer, of T is refeence, maar geen user-defined groups).

Hmmzz.. member functies zijn overgewardeerd. Member functies, zijn gewoon functies met een impliciet vermeld 1e argument (het object waarop je de methode aanroept) en verder heeft dit object beschikking over velden die gewoonlijk niet toegankelijk zijn.

Dit is eigelijk een beetje de klassieke aanpak voor member functies, maar er zijn ook allerlei nieuwe technieken bedacht zoals open objects. Hiermee is het dus mogelijk om buiten een class een functie te gaan declareren waarmee je dezelfde mogelijkheden hebt als een 'klassieke' methode en waar naast single dispatch vaak ook multidispatch aanwezig is (deze methoden heten dan ook wel multimethods).

"Open objects" had C al. Dat zijn gewoon structs. In C++ kun je per member aangeven of die open is. Multi-dispatch is lastiger omdat de bekende methoden daarvoor een relatief grote performance hit hebben, zeker in combinatie met open objects.

Op het moment dat Andrei gaat zeggen dat de 'klassieke' methodes slecht zijn omdat ze gewoon harstikke ouderwets zijn, dan ben ik het 100% met hem eens, maar als hij een ander argument heeft om member functies af te keuren, dan zou ik die graag willen weten.

Methods breken uniforme syntax. Is het A.swap( of swap(A,B)? In C++ moet je kiezen voor swap(A,B) omdat A en B ints zouden kunnen zijn, dus elke swap moet als non-member becschikbaar zijn (op z'n minst).