[C++]Wat is er moeilijk voor beginners ?

[MSalters]

Ik ben aan het kijken of ik wat C++ materiaal kan schrijven voor beginners. Alleen weet ik niet precies wat voor onderwerpen het meest in de smaak vallen. En om nou over Generic Programming te gaan schrijven terwijl driekwart van de lezers geen hout van templates snapt...

Dus, zeg het maar.

Ideetjes:
STL?
Templates?
Exceptions?
Algoritmes?
OO/Patterns?
Boost libraries?
Andere gevallen van ?

( Naar aanleiding van mod commentaar op inhoud van /14 )

[D2k]

oe oe oe
internet (socket) programming

ajb

[.oisyn]

met de inhoud van /14 zit het wel snor, maar die van /38 schijnt om te te zijn

.edit: hmmm deze uitspraak doet mijn front niet veel goeds

.edit2: maar als je toch bezig wilt zijn, schrijf maar een tutorial over 3d convex object collision detection & response, daar heb ik ook nog wat aan

[Korben]

Op maandag 26 november 2001 14:05 schreef OiSyN het volgende:
met de inhoud van /14 zit het wel snor, maar die van /38 schijnt om te te zijn

.edit: hmmm deze uitspraak doet mijn front niet veel goeds

.edit2: maar als je toch bezig wilt zijn, schrijf maar een tutorial over 3d convex object collision detection & response, daar heb ik ook nog wat aan

[off-topic] TDCOCD&R. Hum. Fijne afkorting.

Maareuhm volgens mij bedoelde hij meer items voor beginners (unlike you I suppose ) zoals...

STL?
Templates?
Exceptions?
Algoritmes?
OO/Patterns?
Boost libraries?

* Korben heeft twijfels over OiSyN, die blijkbaar is begonnen met het boek C++ - TDCOCD&R, te vinden bij Studieboeken -> ICT -> Programmeren -> C++ -> Beginners

[Verwijderd]

Op maandag 26 november 2001 14:04 schreef D2k het volgende:
oe oe oe
internet (socket) programming

ajb

Download gewoon een wrapper library zoals common C++. Dan heb je al je socket functies portable (zelfs win32) gewrapped en hoef je niet met raw sockets aan de slag.

[MSalters]

Op maandag 26 november 2001 14:05 schreef OiSyN het volgende:
.edit2: maar als je toch bezig wilt zijn, schrijf maar een tutorial over 3d convex object collision detection & response, daar heb ik ook nog wat aan

Nou, da's wel heel erg simpel:
1: Breek convex object op in set van vierhoeken (dus met
4 driehoekige zijdes )
2: Test elk hoekpunt van ene object of dat in een van de
andere vierhoeken ligt.

[D2k]

Op maandag 26 november 2001 14:24 schreef mietje het volgende:

[..]

Download gewoon een wrapper library zoals common C++. Dan heb je al je socket functies portable (zelfs win32) gewrapped en hoef je niet met raw sockets aan de slag.

das een mooie link: die gaat de bookmarks in


<sneaky mode>
op mijn topic hierover werd niet gereplied dus dan zo maar ff:
Heeft er iemand als eens een PPP verbinding opgebouwd vanuit C/C++ ?
</sneaky mode>

[MSalters]

Op maandag 26 november 2001 14:24 schreef mietje het volgende:

[..]
Download gewoon een wrapper library zoals common C++. Dan heb je al je socket functies portable (zelfs win32) gewrapped en hoef je niet met raw sockets aan de slag.

Ik heb de code net gedownload, en 't is een redelijke poging, alleen niet "zoals het hoort". De standaard manier om een nieuwe output voor een stream te maken is een streambuf klasse. Die zit er wel in, maar heet TCPstream. Bovendien is dat via Multiple Inheritance ook nog een iostream, zoals je zou verwachten met die naam. Dat moeten dus eigenlijk twee klasses zijn.
Aan de andere kant, geteste code is getest. Da's een groot voordeel.

Overigens is een streambuf class een leuke oefening als je wilt oefenen met iets meer dan newbie C++ code. Je zou in een dag een ROT-13 encoder moeten kunnen schrijven als je
alle basis C++ dingen snapt.

[Verwijderd]

Op maandag 26 november 2001 14:47 schreef D2k het volgende:
<sneaky mode>
op mijn topic hierover werd niet gereplied dus dan zo maar ff:
Heeft er iemand als eens een PPP verbinding opgebouwd vanuit C/C++ ?
</sneaky mode>

In unix/linux werk je normaal met het SLIP-protocol als je over serieele poorten werkt, niet met PPP (het moet wel kunnen). Ik heb me er zelf nooit zo mee bezig gehouden, dus weet ik er weinig van, helaas.

[Verwijderd]

Op maandag 26 november 2001 15:11 schreef MSalters het volgende:
Ik heb de code net gedownload, en 't is een redelijke poging, alleen niet "zoals het hoort". De standaard manier om een nieuwe output voor een stream te maken is een streambuf klasse.

Een bekend probleem bij alle stream classes die multithreaded moeten werken. Er moet wat geknoeid worden om de boel thread-safe te krijgen (en dat is die hele library).

[Reefer]

Over een paar maanden ga ik ook C++ leren, dus berg je dan maar alvast
Ik kan alle tutorials dan gebruiken, dus editors aweey !

[D2k]

Op maandag 26 november 2001 15:12 schreef mietje het volgende:

[..]

In unix/linux werk je normaal met het SLIP-protocol als je over serieele poorten werkt, niet met PPP (het moet wel kunnen). Ik heb me er zelf nooit zo mee bezig gehouden, dus weet ik er weinig van, helaas.

helaas moet ik het met ppp doen ivm een implementatie in al bestaande software. Ik heb vorige week al een stuk de ppp source herschreven ( hier ) naar mijn wensen maar ik voel er niet veel voor die complete source van ppp ook in mijn eigen programma te gaan implementeren.
Ik hoopte eigenlijk dat er iemand een goed id had.

[Verwijderd]

D2k>> ik heb iets gevonden in de PPP-HOWTO. Het moet gewoon lukken zonder te gaan source-hacken, volgens mij.

[D2k]

Op maandag 26 november 2001 16:04 schreef mietje het volgende:
D2k>> ik heb iets gevonden in de PPP-HOWTO. Het moet gewoon lukken zonder te gaan source-hacken, volgens mij.

die how-to kan ik al dromen inmiddels
maar het is dus de bedoeling dat het niet vanaf de prompt maar vanuit een C programma gaat gebeuren. En liefst zonder ranzige system call met de parameters die ik nu ook op de prompt gebruik. (maar ik trek wel ff mijn oude topic omhoog dit gaat echt te ver ot)
<Edit> deze
[topic=322258/1]

[Orphix]

Aangezien ik de rest al ken, ben ik persoonlijk het meest geinteresseerd in boost libraries (van wat je daar opnoemde). Dat zie je niet vaak (of ik zoek niet goed genoeg ), zou graag willen weten of het nuttig is om daar veel tijd/energie in te steken.

[vinnux]

Ja dat wilde ook ook gaan proberen, maar dat neemt volgens mij nogal wat tijd in beslag. Maar kun je ons op de hoogte houden daarover ?

Lijkt mij erg interessant.

[.oisyn]

Op maandag 26 november 2001 14:34 schreef MSalters het volgende:

[..]

Nou, da's wel heel erg simpel:
1: Breek convex object op in set van vierhoeken (dus met
4 driehoekige zijdes )
2: Test elk hoekpunt van ene object of dat in een van de
andere vierhoeken ligt.

dan maar even een serieuze reactie op deze (denk ik) niet zo serieuze reactie

1. Je hoeft convex objecten niet op te delen in vierhoeken als je de hoeken wilt gaan testen

2. De hoekpunten hoeven niet persee in het ander object te liggen willen ze elkaar snijden

3. Dit is dus met stilstaande objecten, er moet nog beweging in (lineaire snelheid + rotatie)

4. Waar is het response gedeelte?


Zo, nu jij weer

[reddog33hummer]

als je een beginners tutorial schrijven gaat:

denk vooral dat je dingen als memoryleakage, segmentationfault, enz. goed uitlegd.

Welke dingen zeker en onzeker in c++ zijn:
x->set(a++,a++);
Voor c++ is er geen standaard welke nu eerst uitgerekend (de eerste 'a' of de 2e 'a') wordt. Dingetjes zoals erno lijken mij ook geen overbodige luxe.

en dat het maken van objecten niet altijd lukt

[Verwijderd]

Ik heb een boek over C++ gelezen, snap ik allemaal goed. Hoewel exception handling e.d. daar niet echt in behandelt werden. Elke keer als ik weer aan C++ wil beginnen raar ik het kwijt bij windows programming. Ligt het aan mij of is het echt zo'n rotzooi? Hey! Misschien helpt een tutorial wel!

_{(windows programming dus)}

[Verwijderd]

Templates & STL lijkt me wel wat.

[bloody]

- member functies als callback gebruiken
- dynamische zaken (arrays,structures enz)
- multithreading
- debugging!!

suc6!

[MSalters]

Op maandag 26 november 2001 19:16 schreef reddog33hummer het volgende:
als je een beginners tutorial schrijven gaat:

denk vooral dat je dingen als memoryleakage, segmentationfault, enz. goed uitlegd.

Beginners moeten geen geheugen dynamisch alloceren. Als ze std::vector / std::list gebruiken wordt dat voor ze gedaan,
maar ook het dealloceren gebeurt dan voor ze.
Segfault's zijn denk ik ook daarom ook niet zo belangrijk in C++, omdat je veel minder zelf met pointers loopt te klooien.

Welke dingen zeker en onzeker in c++ zijn:
x->set(a++,a++);
Voor c++ is er geen standaard welke nu eerst uitgerekend (de eerste 'a' of de 2e 'a') wordt. Dingetjes zoals erno lijken mij ook geen overbodige luxe.

en dat het maken van objecten niet altijd lukt

Dat laatste is misschien wel het allerbelangrijkste. Het idee dat een ctor die niet wil, een exception moet gooien, dat verzin je zelf niet (als beginner). Er zijn nog teveel mensen die init() members maken.

[mulder]

Je mag mij nog wel iets uitleggen over recursieve functies, ik weet zeker of dit zo heet maar het volgende voorbeeld gebruikte dit, ik heb dit een keer in Delphi gedaan maar weet bij god niet meer hoe.

Je hebt een vlak van 8 * 8 vierkantjes. In elke rij moet een koningin geplaatst worden. Deze mogen dus niet 'schaak' staan. Dus horizontaal, verticaal en diagonaal niet op 1 lijn zitten. Snappez vous?

[MSalters]

Op dinsdag 27 november 2001 13:49 schreef bloody het volgende:
- member functies als callback gebruiken

Dat is zo simpel, dat kan ik hier wel laten zien.

De grap met member functies is dat ze op een object werken. Als je een member functie als callback wil accepteren, dan moet je dus ook een bijbehorend object accepteren.

Als we de class T noemen, dan heb je dus member functies van het type

code:

ReturnType T::*( Args )

De callback maak je dus via een functie met signature

code:

install_callback( T& object, ReturnType (T::* method)(Args) )

Nu weet je niet vantevoren welke class iemand wil gebruiken, dus je moet een function template gebruiken. Die moet dan een object maken van de callback, met een niet-template base class.

code:

class CallBackBase {
public:
  virtual ReturnType do( Args a ) = 0;
  virtual ~CallBackBase() {;}
};

template< typename T>
class CallBack : public CallBackBase {
  T& object;
  ReturnType (T::* method)( Args );
public:
  CallBack( T& object, ReturnType (T::* method)( Args ) ) :
    object(object), method(method) {;}
  ReturnType do( Args a ) { object.*method( a );
};

template< typename T>
std::auto_ptr< CallBackBase >
install_callback( T& object,
            ReturnType (T::* method)(Args) )
{
  return new CallBack<T>( object, method );
}

De callback kun je nu aanroepen met ->do( args ) zonder
dat je weet uit wat voor class de method komt. Er is wel een heel belangrijk punt in dit ontwerp; het T object wordt niet gekopieerd. Dus dat object moet nog beschikbaar zijn op het moment dat de callback wordt aangeroepen. Je kunt misschien ook kiezen om het object te kopieren ipv een T& te gebruiken, maar dan kun je niet het originele object veranderen. Maar std::cout kun je bijvoorbeeld niet kopieren.

[MSalters]

Op maandag 26 november 2001 15:16 schreef mietje het volgende:

Een bekend probleem bij alle stream classes die multithreaded moeten werken. Er moet wat geknoeid worden om de boel thread-safe te krijgen (en dat is die hele library).

Dat bereik je niet door je classes te mixen. Een formatter ( iostream ) en een IO interface ( streambuf ) zijn twee verschillende objecten.
Bovendien verandert de state van de streambuf veel sneller dan die van de iostream. Des te meer reden om die twee gescheiden te houden.

[bloody]

Op woensdag 28 november 2001 17:22 schreef MSalters het volgende:

een hele berg code

he het was voor beginners!! wat jij daar zegt lijk me NIET voor beginners.

[Verwijderd]

nou ik ben een beginner en ik wou visual c++ leren en ik snap er nogsteeds geen ene reet van.

wat ik wel kan is C programmeren, nou de basis dan. ik kan korte routines schrijven. java kan ik ook perfect, is ook ontzettend makkelijk.

Toen wou ik proberen een java clas in c te zetten.
is me niet gelukt.

wat ik niet snap is de file structuur, in visual bc++ staan er een hele bult bestanden, waar begint hij in gods naam. hoe zit dat met die headers etc.

ik heb ook 2 jaar pascal geprogrammeerd en dat was vrij makkelijk, hij begon boven en gaat naar beneden.

dat is bij vc++ niet echt zo denk ik.

maar dat zou wel makkelijk zijn in de tutorial...

ik zou hem graag ook willen hebben([e-mail]), misschien dat ik dan eindelijk kan beginnen in vc++ 6

[MSalters]

Op donderdag 29 november 2001 16:37 schreef d_maniac het volgende:
nou ik ben een beginner en ik wou visual c++ leren en ik snap er nogsteeds geen ene reet van.

wat ik niet snap is de file structuur, in visual bc++ staan er een hele bult bestanden, waar begint hij in gods naam. hoe zit dat met die headers etc.

ik heb ook 2 jaar pascal geprogrammeerd en dat was vrij makkelijk, hij begon boven en gaat naar beneden.

dat is bij vc++ niet echt zo denk ik.

Je hebt gelijk; van boven naar beneden werkt niet in C++.
Maar het werkt wel hetzelfde als in C.

Een C++ programma bestaat uit een verzameling .cpp files. Die hoeven niet tegelijk gecompileerd te worden. Als er een gecompileerd wordt, dan wordt het een .obj file. Als je alle .obj files hebt kun je er een .exe van maken. Als je een .cpp file verandert, dan hoef je alleen die opnieuw te compileren.

Headers, .h of .hpp, worden letterlijk in de .cpp gezet. Dat betekent dat als je een header verandert, dat je alle .cpp files moet compileren die die header gebruikt.

Een file wordt van boven naar beneden gecompileerd. Als je een functie probeert te gebruiken, die lager staat dan de plek die je wil gebruiken, dan moet je dus ook vantevoren vertellen dat er zo'n functie ergens staat. Dat doe je door de functie declaratie, net zoals in C.

[.oisyn]

_{subtiele toevoeging}

en die functiedeclaraties staan dus in de header files

[MSalters]

Op donderdag 29 november 2001 16:18 schreef bloody het volgende:

[.. boel code van mij ]

he het was voor beginners!! wat jij daar zegt lijk me NIET voor beginners.

Daar heb je gelijk in. Ik begon gewoon met schrijven, en toen kwam ik erachter dat als je ALLE classes als callback wil kunnen gebruiken, dat je dan een template moet gebruiken. Dus toen moest ik overal template< > boven zetten. En dan wordt't een boel, ja.

OO callbacks zijn sowieso niet voor beginners. Het voordeel van C++ is dat je ook nog simpele functies hebt.

[.oisyn]

als je echt callbacks wilt hebben dan hoor je dat eigenlijk te doen met een interface

code:

class CallbackInterface
{
public:
    virtual void callback ()
};

// hier een functie die wat met die callback gaat doen
void blaat (CallbackInterface & c)
{
    ...
    c.callback ();
    ...
}


// en je functie declareer je vervolgens zo
class MyClass : public CallbackInterface
{
    // hier natuurlijk nog andere troep zoals een constructor enzo

    void callback ()
    {
      // jouw callback code hier
    }
}



int main ()
{
    MyClass myclass;

    blaat (myclass);

    return 0;
}

en ook wat begrijpelijker voor de beginnende coder

[mbravenboer]

MSalters legde het compilatie proces van C++ even uit

Wat is alles toch eenvoudig als het duidelijk wordt uitgelegd .

[Orphix]

Op vrijdag 30 november 2001 01:10 schreef OiSyN het volgende:
als je echt callbacks wilt hebben dan hoor je dat eigenlijk te doen met een interface

Ja maar ik denk niet dat dit wordt bedoelt met member callbacks. Eigenlijk zit je in dit stukje gewoon via een functie een (virtual) method aan te roepen van een object.
De kunst is om een object 'aan te sluiten' op een ander object. Wanneer die een signaal afgeeft (callback aanroept) kan het andere object daarop reageren. En ja, helaas moet dit heel complex gebeuren. Als voorbeeld kan je kijken naar libsigc++, een cross-platform signal-slot systeem.

[mbravenboer]

Orphix: Ja maar ik denk niet dat dit wordt bedoelt met member callbacks. Eigenlijk zit je in dit stukje gewoon via een functie een (virtual) method aan te roepen van een object.

En waarom zou je dat in mindere mate een member callback mogen noemen?

* mbravenboer is het eigenlijk wel met OiSyN eens .

[Orphix]

Omdat ik een interface geen member callback vind. IMHO is een callback wanneer een object een functie aanroept van of een globale functie of een member funtie van een ander object. De kunst is die verbinding te maken op een elegante manier. In de methode van OiSyN geef je niet aan de objecten mee welke functies moeten worden aangeroepen bij bepaalde gebeurtenissen (callbacks).
Wat OiSyN doet vind ik meer een vorm van abstractie door de interface op te delen in verschillende delen (classen). Op die manier kunnen veel verschillende classes die interface ondersteunen (omdat het vrij specifiek is).

[mbravenboer]

Orphix: In de methode van OiSyN geef je niet aan de objecten mee welke functies moeten worden aangeroepen bij bepaalde gebeurtenissen (callbacks).

Dat kan toch door in de interface verschillende functies op te nemen voor de verschillende gebeurtenissen? Op die manier leg je gelijk op een duidelijke manier vast welke events er mogelijk zijn. Ik begrijp je probleem ermee wel, maar het zorgt toch wel voor duidelijkere code?

[Orphix]

Maar met deze methode kan je niet 2 'blinde' objecten aan elkaar knopen. Object A verwacht als callback een int functie(int parm);
Object A kent geen interface van de andere kant.. al helemaal geen toekomstige interfaces. Dan werkt deze methode toch niet

[mbravenboer]

Orphix: Maar met deze methode kan je niet 2 'blinde' objecten aan elkaar knopen.

Das waar (denk ik ), er wordt gecommuniceerd via de interface. Die interface moet de een accepteren en de ander implementeren. Uiteraard kan je wel een zeer generieke interface maken als je dat wilt...

Allebei dus goede toepassingen?

[Orphix]

Op vrijdag 30 november 2001 03:16 schreef mbravenboer het volgende:
Allebei dus goede toepassingen?

Hehe deal
ik geef toe de methode van OiSyN is veel mooier, maar als ik bv een library schrijft wil ik toch liever niet de gebruiker verplichten allerlei interfaces voor hun (bestaande) klasses als parent-classes te gaan gebruiken.
Nouja het juiste middel voor het juiste doel he
(en nu )

[MSalters]

Op vrijdag 30 november 2001 03:16 schreef mbravenboer het volgende:

[..]

Das waar (denk ik ), er wordt gecommuniceerd via de interface. Die interface moet de een accepteren en de ander implementeren. Uiteraard kan je wel een zeer generieke interface maken als je dat wilt...

Allebei dus goede toepassingen?

Met templates proggen heet niet voor niets "generic programming".

In principe heb je in C++ twee types polymorphisme; compile-time en run-time. Compile-time doe je met templates, en klasses met identieke members. Run-time doe je met inheritance, en virtual functies.

En voor dit probleem heb je allebei nodig. Je hebt een runtime dependancy (dat is het hele idee van de callback), dus heb je virtual functies nodig. Maar als je niet kunt garanderen dat de method die je wil aanroepen virtual is, dan moet je daar dus een wrapper class omheen doen. En die wrapper is dus een template, omdat-ie alles moet kunnen wrappen. En dan kom je op de lap code daarboven uit.

[MSalters]

Op vrijdag 30 november 2001 00:57 schreef OiSyN het volgende:
_{subtiele toevoeging}

en die functiedeclaraties staan dus in de header files

Vaak.

Alleen, als je voor je class nog drie helper functies hebt, die niemand hoeft te zien, dan hoeven de functiedeclaraties dus niet in een header. Headers zijn voor je publieke interface.

B.v

code:

X.h:

class X { 
  X();    // declaratie van member
  virtual ~X();
}

X.cpp:

void helper1(); // declaraties
void helper2();
void helper3();

X::X()  { helper1(); helper2(); } // definitie.
X::~X() { helper2(); helper3(); }

void helper1() // definitie.
{
  std::cout << "helper1" << std::endl;
}
...

Simpele regel: Definities kosten geheugen; declaraties niet.

[mbravenboer]

MSalters: Met templates proggen heet niet voor niets "generic programming".

Mwah, dat generic programming valt nog wel iets mee, maar het is er inderdaad wel een vorm van. In principe kan je alle vormen van polymorphisme wel generic programming noemen. Luca Cardelli hebben een beroemd stuk hierover geschreven. Ze onderscheiden:

1. Ad-hoc polymorphisme
a) Coercion
b) Overloading

2. Universal polymorphisme
a) Parametric
b) Inclusion

Veel van deze vormen worden al at-compile time toegepast (dus niet alleen templates). Coercion wordt bijvoorbeeld toegepast voor het optellen van ongelijke types. 1 van de twee types wordt dan automatisch geconverteerd naar de ondere (als je bijvoorbeeld een double bij een int optelt, de int zal dan geconverteerd worden naar een double).

Overloading is ook een hele makkelijke vorm van polymorphisme, die ook at-compile time wordt toegepast. Bij overloading kan dezelfde operatie op meerdere types worden toegepast, maar de implementatie van de operator verschilt voor de verschillende typen. De bekendste vorm van overloading is natuurlijk + en * voor double, int long etc. Ook dit is dus een vorm van polymorphisme!

De interessantere vormen van polymorphisme (parameteric en inclusion) werken via generieke data-types. Deze kan je bereiken door een data-type te parameterizeren of door sub-typing. De parameterizatie van een klasse (via templates) in C++ is eigenlijk een hele simplistische, maar wel handige vorm.

[MSalters]

Op maandag 03 december 2001 11:44 schreef mbravenboer het volgende:

[..]
De interessantere vormen van polymorphisme (parameteric en inclusion) werken via generieke data-types. Deze kan je bereiken door een data-type te parameterizeren of door sub-typing. De parameterizatie van een klasse (via templates) in C++ is eigenlijk een hele simplistische, maar wel handige vorm.

De C++ vorm is handig voor simplistische vormen. I.h.a. is het namelijk niet simplistisch. Je kunt alle theoretische informatica problemen oplossen met templates (dwz de template taal is compleet) maar de syntax is daarvoor eigenlijk niet gemaakt.

Heb je de code wel eens gezien die compile-time alle priemgetallen onder de N berekende? Het idee was dat je classes priem<N> kreeg. priem<2>::is_priem was een const bool die true was; priem<4>::is_priem was een const bool die false was.

[.oisyn]

Op maandag 03 december 2001 11:35 schreef MSalters het volgende:

[..]

Vaak.

ik bedoelde ook niet dat ze altijd daar moeten staan, ik bedoelde dat dat nou het hele idee was van header files

Alleen, als je voor je class nog drie helper functies hebt, die niemand hoeft te zien, dan hoeven de functiedeclaraties dus niet in een header. Headers zijn voor je publieke interface.

[.. lap code ..]

dat soort helper functies wil je vaak static hebben, zodat code in andere object files niet eens die functies kan aanroepen (en ook weer minder gezeik met naamconflicten e.d.)

[MSalters]

Op maandag 03 december 2001 15:12 schreef OiSyN het volgende:

[... helper functies ... ]

dat soort helper functies wil je vaak static hebben, zodat code in andere object files niet eens die functies kan aanroepen (en ook weer minder gezeik met naamconflicten e.d.)

Je bedoelt, in de unnamed namespace ? "static" is te
verwarrend.

Oh, en je kunt functies best aanroepen vanuit andere
object files, ook al is-tie static:

static int i;
int* ptri = &i;
en
static void f() {;}
void (*ptrf)() = &f;

[mbravenboer]

MSalters: De C++ vorm is handig voor simplistische vormen. I.h.a. is het namelijk niet simplistisch. Je kunt alle theoretische informatica problemen oplossen met templates (dwz de template taal is compleet) maar de syntax is daarvoor eigenlijk niet gemaakt.

Ik ben wel benieuwd wat je met 'alle theoretische informatica problemen bedoelt'. Je kunt in ieder geval sowieso al niet alle generiek programmeren problemen (op een acceptabele manier) oplossen met behulp van templates. Simpelweg alleen al door het ontbreken van een universeel data-type. Als je gaat kijken naar wat in de wetenschappelijke wereld onder echt generiek programmeren wordt verstaan kom je al snel bij zeer bijzondere taaltjes terecht. Zelfs een taal als Haskell wordt dan al niet meer als geschikt gezien. Polytypic programmen (zoals bijvoorbeeld PolyP) gaat zelfs nog een enorme stap verder dan Haskell. Ik denk dat C++ templates zelfs al qua toepasbaarheid zwaar inferieur zijn aan de mogelijkheden van Haskell. Overigens zijn is de Java Generics uitbreiding geen cent beter (en wellicht zelfs slechter, doch eenvoudiger).

Dat stukje van Cardelli is echt heel boeiend om te lezen. Er wordt overal naar verwezen. hier kan je het vinden.

M'n afstudeer begeleider heeft hier ook een zeer interessant stuk over geschreven in z'n proefschrift. Hij had wat verregaande ideeen over methoden of type-niveau. Het is ook online te vinden, maar wel heel erge strong-stuff .

[MSalters]

Op dinsdag 04 december 2001 23:41 schreef mbravenboer het volgende:

[..]

Ik ben wel benieuwd wat je met 'alle theoretische informatica problemen bedoelt'. Je kunt in ieder geval sowieso al niet alle generiek programmeren problemen (op een acceptabele manier) oplossen met behulp van templates.

Er is een vrij bekende stelling in de informatica, die stelt dat er een klasse problemen is die door een Turing machine kan worden opgelost, en dat elke taal waarin je een Turing machine kan programmeren dus die problemen kan oplossen. En problemen die zo'n Turing machine niet kan oplossen, kun je ook niet met bestaande computers oplossen,
want een Turing machine kan op zijn beurt weer alle bestaande computers emuleren.
Dus verschillende computers/talen doen misschien langer/korter over de oplossing, maar als er 1 het probleem kan oplossen, dan kunnen ze het allemaal.

Simpelweg alleen al door het ontbreken van een universeel data-type. Als je gaat kijken naar wat in de wetenschappelijke wereld onder echt generiek programmeren wordt verstaan kom je al snel bij zeer bijzondere taaltjes terecht. Zelfs een taal als Haskell wordt dan al niet meer als geschikt gezien. Polytypic programmen (zoals bijvoorbeeld PolyP) gaat zelfs nog een enorme stap verder dan Haskell. Ik denk dat C++ templates zelfs al qua toepasbaarheid zwaar inferieur zijn aan de mogelijkheden van Haskell. Overigens zijn is de Java Generics uitbreiding geen cent beter (en wellicht zelfs slechter, doch eenvoudiger).

Vrijwel elke taal heeft een universeel datatype, int of zo. Hoe je dat gebruikt is een tweede, maar ik kan bv. in 3 ints een floating point type zetten. Goed, in de praktijk is het niet zo efficient als het ingebouwde, maar in theorie is het net zo goed.

[Wokker]

mischien iets met sql connectie's ??

[mbravenboer]

MSalters: Dus verschillende computers/talen doen misschien langer/korter over de oplossing, maar als er 1 het probleem kan oplossen, dan kunnen ze het allemaal.

Uiteraard, daarom stond er ook tussen haakjes "op een acceptabele manier". Dat C++ Turing-compleet is, is natuurlijk heel interessant als je theoretisch wilt bewijzen dat C++ alle theoretische informatica problemen op kan lossen, maar veel minder interessant als je praktisch ook daadwerkelijke alle theoretische informatica problemen op wilt gaanb lossen.

Vrijwel elke taal heeft een universeel datatype, int of zo. Hoe je dat gebruikt is een tweede, maar ik kan bv. in 3 ints een floating point type zetten. Goed, in de praktijk is het niet zo efficient als het ingebouwde, maar in theorie is het net zo goed.

Met een universeel datatype doel ik absoluut niet op een int . Het gaat bij een universeel datatype sowieso niet om primitieven zoals floats of ints. Jij doelt volgens mij meer op het verschil tussen basic typen en geconstructueerde typen.

Het gaat hier echter vooral om data-structuren met typen en constructoren. Deze kan je in de meeste echte generieke programmeertalen gebruiken via een universeel datatype. Bij een universeel datatype kan je via een bepaalde universeel model al deze typen verwerken en zo generieke procedures over deze datatypen schrijven.

Dit zie je terug in PolyP, Stratego (A-termen) en in een bepaalde vorm ook bij XML. In Java en veel andere talen kan je het ook in een ranzigere vorm gebruiken mbv reflectie. In C++ kan je het ook vast in een wellicht nog ranzigere vorm uitdrukken, maar dat verdient zeker niet de benaming universeel datatype .

[Verwijderd]

Ik geloof dat deze hele discussie al moeilijk is voor beginners.

[MSalters]

Op vrijdag 07 december 2001 21:10 schreef mbravenboer het volgende:

Uiteraard, daarom stond er ook tussen haakjes "op een acceptabele manier". Dat C++ Turing-compleet is, is natuurlijk heel interessant als je theoretisch wilt bewijzen dat C++ alle theoretische informatica problemen op kan lossen, maar veel minder interessant als je praktisch ook daadwerkelijke alle theoretische informatica problemen op wilt gaan lossen.

als je alle problemen wilt oplossen ?
Ben je wel effe bezig

Maar goed, 't punt was over de template taal in C++, het is triviaal dat de runtime Turing-compleet is. Mijn punt is dat de compiler een weakly-typed Turing-complete taal intepreteert om het uiteindelijk te compileren programma te krijgen.