[Alg/C++] C++ als functionele programmeertaal ?

[farlane]

Herb Sutter schreef in C++ users journal dit :
http://www.cuj.com/documents/s=8464/cujcexp0308sutter/
artikel.

Mijn indruk is dat deze library die std::function gaat heten, C++ sterke overeenkomsten gaat geven met een functionele programmeertaal. ( Alhoewel deze lib geen uitbreidingen aan de taal C++ zelf nodig heeft ! )
Maw, de C++'ers onder ons kunnen in de toekomst ook functies chainen.

Mbv deze library is het mogelijk om functies als parameter te gebruiken, en als returntype. Itt tot normale functiepointers echter is het niet nodig om een exacte match te hebben mbt het functieprototype.

Dit :

C++:

std::function
< std::string ( std::string ) > stringfunc;

Zou je dus kunnen binden aan een globale functie die een string neemt als parameter en een string returned, maar ook een memberfunctie van een classe komt in aanmerking, en zelfs een (member)functie die een char * als parameter heeft en een char * retourneert.

Natuurlijk heeft een fp taal meer eigenschappen dan deze, maar ik ben benieuwd of fp aanhangers dit zien als een goede stap ? Of is het geen oplossing voor wat de fp'ers willen?
En de mensen die voornamelijk de C in C++ gebruiken, en amper de ++, wat vinden die ervan ? Is het in de praktijk bruikbaar, of gebruiken we toch liever een functie die void pointers gebruikt ?

[djazete]

het klinkt handig, maar volgens mij wordt het sowieso niet voor niks opgenomen in de stl. Ik denk dat het de mogelijkheden van om in een bepaalde stijl te programmeren weer vergroot, en dat je daardoor misschien een bepaald type applicatie of bepaalde oplossingen netter of sneller of efficienter kunt maken..?

Nou ben ik niet zo'n C++ kenner maar dat is zo even wat mij te binnen schoot (ben net begonnen aan Bjarne Stroustrup's boek..)

[Janoz]

Voor zover ik kan zien veranderd er weinig aan de werkelijke functionalitiet. Het is alleen wat moeilijker om bugs te maken. Om het functioneel programmeren te noemen gaat mij veel te ver. Dat heeft namelijk hele andere eigenschappen.

[Verwijderd]

Tja, erg leuk dat ze proberen functionele dingen na gaan doen. En het zal best wel werken(lees: de computer zou het uitvoeren), maar als je serieus verwacht dat ik ooit een regel code op deze manier zal produceren, dan zit je fout.

C++ en Haskell zitten qua design-idee, zover van elkaar af, dat het niet praktisch is, om er functioneel in te programmeren.

Ik ben ook van mening dat in elke taal, zoveel mogelijk door de compiler moet worden afgeleid, om er maar voor te zorgen dat de syntax niet lelijk wordt(wat nu dus gebeurd). Iets dat al bij bijvoorbeeld Clean(lees: Ugly) is gebeurd (zie website Clean).

[farlane]

Janoz schreef op 25 August 2003 @ 12:06:
Voor zover ik kan zien veranderd er weinig aan de werkelijke functionalitiet. Het is alleen wat moeilijker om bugs te maken. Om het functioneel programmeren te noemen gaat mij veel te ver. Dat heeft namelijk hele andere eigenschappen.

Tuurlijk, de functionaliteit van de taal C++ verandert niet, maar naar mijn idee geeft dit toch een optie om mbv standaard C++ ( als in 'C++ + standaard libs' ) een fp achtige applicatie in elkaar te zetten. ( Ik heb het overigens met opzet geen fp genoemd, maar aangegeven dat het overeenkomsten heeft met fp. )

Welke eigenschappen van fp mis je nog hierin ?

[edit]

Ik ben ook van mening dat in elke taal, zoveel mogelijk door de compiler moet worden afgeleid, om er maar voor te zorgen dat de syntax niet lelijk wordt(wat nu dus gebeurd).

Ik vind het voorbeeld dat hij onderaan geeft :

C++:

function<int (int x, int y)> arithmetic_operation(char k)
{
  switch (k) {
    case '+': return plus<int>();
    case '-': return minus<int>();
    case '*': return multiplies<int>();
    case '/': return divides<int>();
    case '%': return modulus<int>();
    default: assert(0);
  }
}

verre van lelijk, maar misschien is dat een van die dingen die fp'ers dan graag anders zien : de syntax.

[ Voor 34% gewijzigd door farlane op 25-08-2003 12:20 ]

[mbravenboer]

Natuurlijk heeft een fp taal meer eigenschappen dan deze, maar ik ben benieuwd of fp aanhangers dit zien als een goede stap?

Ik zie als belangrijkste voordeel dat standaardisatie van zo'n generieke function interface ervoor zorgt dat je je functies beter kan hergebruiken in verschillende APIs. Dat is een duidelijk pluspunt. Met Java Generics zie je bijvoorbeeld dat mensen ook opeens op het idee komen om functies te gaan schrijven. Omdat er geen standaard interface is, krijg je een hoop verschillende interfaces, waardoor de functies niet uitwisselbaar zijn. Das knudde.

Of is het geen oplossing voor wat de fp'ers willen?

Nee, dat denk ik niet. Naast de theoretische argumenten dat de taal natuurlijk niet puur en lazy is, is het grootste probleem de typering. Bij deze manier van functioneel programmeren moet je van elk wisse wasje (? ) het type opgeven, waar je volledig gestoord van wordt. Je moet dus echt type inferentie hebben.

[farlane]

mbravenboer schreef op 25 August 2003 @ 12:15:
Bij deze manier van functioneel programmeren moet je van elk wisse wasje (? ) het type opgeven, waar je volledig gestoord van wordt. Je moet dus echt type inferentie hebben.

Wat ik uit het artikel begreep is dat alle types die impliciet naar elkaar kunnen worden gecast al voldoen.

Mijn kennis van fp gaat niet erg ver ( understatement ), maar zou je kunnen aangeven waar een 'native fp' taal wel uit de voeten zou kunnen, en die std::function niet ?

[edit]

wis·se·was·je (het ~, ~s)
1 onbeduidend iets, onbenulligheid => kleinigheid

[ Voor 11% gewijzigd door farlane op 25-08-2003 12:28 ]

[RickN]

farlane schreef op 25 August 2003 @ 12:14:
[...]


Tuurlijk, de functionaliteit van de taal C++ verandert niet, maar naar mijn idee geeft dit toch een optie om mbv standaard C++ ( als in 'C++ + standaard libs' ) een fp achtige applicatie in elkaar te zetten. ( Ik heb het overigens met opzet geen fp genoemd, maar aangegeven dat het overeenkomsten heeft met fp. )

Welke eigenschappen van fp mis je nog hierin ?

[edit]


[...]

-Lazy evaluation,
-Partiële parametrisatie (Ik maak tenminste nergens uit op dat het deze eigenschap bezit)

De enige overeenkomst lijkt haast wel dat je _een beetje_ de syntax van een fp taal kunt benaderen....

[Alarmnummer]

farlane schreef op 25 augustus 2003 @ 12:25:
[...]
Mijn kennis van fp gaat niet erg ver ( understatement ), maar zou je kunnen aangeven waar een 'native fp' taal wel uit de voeten zou kunnen, en die std::function niet ?

Zoals mbravenboer al aangaf is lazyness vrij gebruikelijk bij functionele programmeertalen. Bij een pure functionele programmeertaal heeft een functie geen effecten op de wereld en kan dus alleen iets laten zien door een bepaalde waarde terug te sturen. Hierdoor maakt het ook niet uit wanneer een functie uitgevoerd gaat worden, dus je zou de berekening ook achter een thunk (virtual proxy voor de design patterns liefhebbers) plaatsen. Pas als het nodig is hoeft die waarde bepaald te worden. Hierdoor kan je op een hele andere manier gaan proggen.

[Alarmnummer]

RickN schreef op 25 August 2003 @ 12:26:
-Partiële parametrisatie (Ik maak tenminste nergens uit op dat het deze eigenschap bezit)

Partiele parametrisatie is ook iets dat gerust zou kunnen in andere talen, dat is niet een specifieke eigenschap van functionele talen.

[edit]
alhoewel ik het alleen nog maar heb gezien in Clean en Haskell.

De enige overeenkomst lijkt haast wel dat je _een beetje_ de syntax van een fp taal kunt benaderen....

In het land der blinden is eenoog koning

[ Voor 8% gewijzigd door Alarmnummer op 25-08-2003 12:33 ]

[.oisyn]

Overigens bestond veel van dit soort functionaliteit al lang in de STL. Er wordt in de STL sowieso voornamelijk gewerkt met functors en geen functies. En kijk eens naar de functional header, waar je bijvoorbeeld met bind1st () en bind2nd () een binary functie/functor kunt converteren naar een unary functor door alvast 1 parameter op te geven, die je vervolgens weer als argument kunt meegeven aan iets dat een unary functie/functor verwacht.

En verder nog allemaal voorgedefinieerde binary functies/functors voor standaard operatoren, zoals +, -, *, etc. en vergelijkingsoperatoren

[mbravenboer]

farlane: Mijn kennis van fp gaat niet erg ver ( understatement ), maar zou je kunnen aangeven waar een 'native fp' taal wel uit de voeten zou kunnen, en die std::function niet ?

Het is sowieso zinloos om over mogelijkheden te praten omdat alles natuurlijk mogelijk is . Het gaat vooral om de verbositeit van de functionele manier van werken. Dit gaat dan met name om het aangeven van typen van functies, maar om bijvoorbeeld functie compositie, lijsten en tuples maken enz.

Het zou nuttig zijn om eens wat zaken concreet in code te vergelijken: functie compositie, partiele toepassing van functies, lijsten, hogere orde functies enz.

[mbravenboer]

RickN: -Partiële parametrisatie (Ik maak tenminste nergens uit op dat het deze eigenschap bezit)

Dat valt ook wel zelf te simuleren (allemaal functies met slechts 1 argument die weer functies opleveren). Ook hier gaat dus weer om de compactheid van de notatie.

[RickN]

Alarmnummer schreef op 25 augustus 2003 @ 12:29:
[...]

Partiele parametrisatie is ook iets dat gerust zou kunnen in andere talen, dat is niet een specifieke eigenschap van functionele talen.

[edit]
alhoewel ik het alleen nog maar heb gezien in Clean en Haskell.


[...]

In het land der blinden is eenoog koning

Oké, maar als je het zo bekijkt is er erg weinig dat een specifieke eigenschap is van functionele talen...
Lazy evaluation kan dan ook wel, en een imperatieve taal clean maken ook, door procedures en globale variablen te verbieden en alle "communiatie" via functie parameters en return values te laten verlopen, maar voorlopig vind ik dat allemaal nog vrij specifiek voor functionele talen....

Wat mbravenboer al zegt, het is voornamelijk een notatie issue, en een hele andere manier van kijken naar programmeer problemen. Functionele talen zijn nu eenmaal niet krachtiger dan imperatieve....

[ Voor 13% gewijzigd door RickN op 25-08-2003 12:42 ]

[hobbit_be]

offtopic:
[quote]Alarmnummer schreef op 25 August 2003 @ 12:29:
[...]
In het land der blinden is eenoog koning :)[/quote]

Dan moet je maar eens "Country Of The Blind" van H.G. Wells lezen

[ Voor 51% gewijzigd door hobbit_be op 25-08-2003 12:48 ]

[Alarmnummer]

RickN schreef op 25 August 2003 @ 12:39:
[...]


Oké, maar als je het zo bekijkt is er erg weinig dat een specifieke eigenschap is van functionele talen...
Lazy evaluation kan dan ook wel, en een imperatieve taal clean maken ook, door procedures en globale variablen te verbieden en alle "communiatie" via functie parameters en return values te laten verlopen, maar voorlopig vind ik dat allemaal nog vrij specifiek voor functionele talen....

Dat zou idd ook kunnen, en verder kan je met design patterns zoals een virtual proxy ook lazyness simuleren.

Ik zit zelf ook wel eens met de gedachte waar je een taal onder moet gaan schuiven omdat het bepaalde eigenschappen wel of niet heeft. Ik kom dan vaak weer uit dat een taal in grote lijnen lijkt op iets, maar dat je nooit iets volledig in een hokje moet gaan drukken omdat onnodig beperkt en ook zinloos is.

Wat mbravenboer al zegt, het is voornamelijk een notatie issue, en een hele andere manier van kijken naar programmeer problemen. Functionele talen zijn nu eenmaal niet krachtiger dan imperatieve....

*geeft RickN een helm en een kogelvrij vest*

[RickN]

Alarmnummer schreef op 25 August 2003 @ 12:48:
[...]
Ik zit zelf ook wel eens met de gedachte waar je een taal onder moet gaan schuiven omdat het bepaalde eigenschappen wel of niet heeft. Ik kom dan vaak weer uit dat een taal in grote lijnen lijkt op iets, maar dat je nooit iets volledig in een hokje moet gaan drukken omdat onnodig beperkt en ook zinloos is.

*Volledig ermee eens is

En het werkt ook de andere kant op, kijk maar naar monads in Haskell, dan lijkt dan weer erg op imperatief.

Alarmnummer schreef op 25 August 2003 @ 12:48:
*geeft RickN een helm en een kogelvrij vest*

Oeh, zal ik dan even snel refrasen!

Beide varianten kunnen turing complete zijn. Ik zeg hiermee verder niks over de uitdrukkings kracht van expressies in de taal.......

[ Voor 48% gewijzigd door RickN op 25-08-2003 12:57 ]

[farlane]

RickN schreef op 25 August 2003 @ 12:39:
[...]
Wat mbravenboer al zegt, het is voornamelijk een notatie issue, en een hele andere manier van kijken naar programmeer problemen. Functionele talen zijn nu eenmaal niet krachtiger dan imperatieve....

Oops, iets zegt me dat er mensen zijn die hier anders over denken ...

Waar het op neer komt is dus kennelijk dat alles wat je met een fp zou willen doen ook met C++ ( of taal X ) zou kunnen doen, ware het niet dat de notatie van die taal dan waarschijnlijk erg in de weg zou zitten ? Maw, het grootste voordeel van een fp is de syntax, omdat je blijkbaar veel van de andere eigenschappen zelf kunt bouwen ( al dan niet wegggestopt in een standaard library ) ?

[edit]
Nu ik dit zo lees, en de reactie van RickN hierna is dit een behoorlijke open deur ....

[ Voor 8% gewijzigd door farlane op 25-08-2003 13:01 ]

[RickN]

Uiteraard, alles kan toch met C?!

[ Voor 90% gewijzigd door RickN op 25-08-2003 12:57 ]

[Verwijderd]

Ja, de syntax en betekenis daarvan is gewoon zo gemaakt, dat je heel makkelijk krachtige abstracties kunt maken. Ik heb bijv. een XML-Parser gemaakt met PARSEC(Parser Combinator Lib), waarbij mijn code 20(!) regels was.
Het grappige is dat ik eigenlijk mijn god niet zou weten waar ik in JAVA/C/C++ zou moeten beginnen om zelf een parser te maken. Bij C rinkelt dan nog wel YACC, geloof ik, maar als je gewoon on-the-fly een parser kan maken, dan is dat niet verkeerd. Ik wil weer niet zeggen dat het niet in een andere taal, zou kunnen, maar ik wil alleen zeggen dat het in een andere taal vele krommer wordt beschreven.

Het is in Haskell volgens mij ook een sport, om nooit saai te worden. En het mooie is ook dat ik nog nooit een abstractie heb nodig gehad, die niet te maken was met Haskell, maar wel in andere talen.

[mbravenboer]

gang-ster: Ik heb bijv. een XML-Parser gemaakt met PARSEC(Parser Combinator Lib), waarbij mijn code 20(!) regels was.

Tja, die vergelijking is natuurlijk niet zo eerlijk. Je kan zelfs met parser combinators in 20 regels nog geen xml parser implementeren die aan de xml standaard voldoet (laten we dtd daar zelfs nog buiten laten).

[Verwijderd]

mbravenboer schreef op 25 August 2003 @ 13:14:
[...]

Tja, die vergelijking is natuurlijk niet zo eerlijk. Je kan zelfs met parser combinators in 20 regels nog geen xml parser implementeren die aan de xml standaard voldoet (laten we dtd daar zelfs nog buiten laten).

Ok een subset dan...

[Soultaker]

Om maar weer even on-topic te komen: ik vind deze functietypen een stuk mooier dan de in de STL gebruikelijke functors; ik vond het altijd al een beetje zinloos om een nieuw type te moeten definieren met daarin een functie, als je alleen die functie zelf wilt gebruiken. In theorie zou je het type kunnen gebruiken om andere gegevens in op te slaan (die tussen de aanroepen van de functie door bewaard moeten blijven) maar in de praktijk komt dat vaker niet dan wel voor (en dan zijn er ook nog static lokale variabelen); het is dus veel beter als dit als uitzondering op de regel wordt gezien (en als ik het goed begrijp is het met die function template ook nog gewoon mogelijk) dan als de regel zelf.

Wat ik jammer vind aan dit soort template trucjes in het algemeen (en ook aan deze specifiek, dus) is dat het het gebruik van C++ ontzettend ingewikkeld maakt. Misschien ben ik een bovengemiddeld domme C++-programmeur, maar ik vind het altijd ontzettend moeilijk om in m'n achterhoofd te houden wat er nu precies gebeurt als ik al die verschillende templates combineer en na te gaan of de gebruikte constructies de door mij gewenste semantiek hebben. Een beetje hetzelfde verhaal als met Perl eigenlijk, maar hoewel ik het me in Perl meestal wel kan veroorloven om enigzins suboptimale code te schrijven, gebruik ik C++ juist als performance van een groot belang is. Om die performance op peil te houden is een goed begrip van wat er achter de schermen gebeurt (en wat de compiler allemaal wel en niet kan optimaliseren) erg belangrijk.

Ik kan me dus voorstellen dat als je deze functies gaat combineren met andere template constructies en dan met impliciete conversies tussen strings en char* gaat werken, het vrij lastig wordt om in te zien of er niet onnodig veel geconverteerd of gekopieerd gaat worden. Hoewel ik constructies als deze dus zeker de moeite waard vind (al is het alleen maar om het "leuk!" effect wederom net als bij talen als Perl), lijkt het me voor een beginnende C++-programmeur vrij lastig om code met dit soort constructies erin goed te kunnen teruglezen.

[.oisyn]

Soultaker schreef op 25 August 2003 @ 16:43:
Om maar weer even on-topic te komen: ik vind deze functietypen een stuk mooier dan de in de STL gebruikelijke functors; ik vond het altijd al een beetje zinloos om een nieuw type te moeten definieren met daarin een functie, als je alleen die functie zelf wilt gebruiken.

hoeft niet, de STL werkt ook gewoon met normale functies. Het nadeel daarvan is echter dat je het hele type ook mee moet geven bij de template arguments als het een klasse betreft.

Wat echter wel vervelend is is dat C++ niet de mogelijkheid heeft om locale functies te definieren. En dan kun je wel een locale functor definieren, maar die kun je weer niet gebruiken voor template arguments, omdat het een local type is. 2 dingen die ze imho eigenlijk nog moeten wijzigen

In theorie zou je het type kunnen gebruiken om andere gegevens in op te slaan (die tussen de aanroepen van de functie door bewaard moeten blijven) maar in de praktijk komt dat vaker niet dan wel voor (en dan zijn er ook nog static lokale variabelen); het is dus veel beter als dit als uitzondering op de regel wordt gezien (en als ik het goed begrijp is het met die function template ook nog gewoon mogelijk) dan als de regel zelf.

punt is alleen dat als je alleen functies toelaat, dat je dan automatisch al geen functors kunt meegeven. Een functie kun je converteren naar een functor, andersom niet

[MSalters]

Als je naar C++ parsers gaat kijken, dan kom je gauw bij Spirit uit. Dat is een library die duidelijk verwant is aan de std::function voorstellen. Dankzij operator overloading kun je daarmee EBNF bijna ongewijzigd compileren als C++, het resultaat van de transformatie is nog goed herkenbaar.

Wat terecht wordt opgemerkt is dat C++ onhandelbaar wordt, als je alle types moet uitschrijven. Gelukkig is er een typeof aanstaande.

Een van de doelen van C++ is om de compactheid van uitdrukkingen evenredig te maken met de frequentie van gebruik. ++i is een goed voorbeeld van een veelgebruikte uitdrukking die ook compact is. Aangezien deze constructies waarschinlijk relatief zeldzaam zullen blijven hoeven ze niet heel erg compact te worden. Evengoed vindt ik

code:

(std::cout << _1 << std::endl)

als uitdrukking erg leesbaar. Voor alle duidelijkheid, het is een expressie voor een unary functie die z'n argument op een verder lege regel zet. Zoiets zou je dus aan een unary std::function kunnen assignen.

[RickN]

Laat ik even een, verder niet (door mij) met uit enquetes voortgekomen resultaten te staven, losse opmerking uit de pols neerpennen:

Mensen die functioneel willen programmeren zullen dit doen in een echte functionele taal, mede door de inherent in zo'n taal aanwezige notationele schoonheid, en niet in een halfbakken, geforceerde oplossing in een willekeurige imperatieve taal.

Ergo, zonde van de moeite.

_{Nu duck ik dus wel voor cover}

[ Voor 15% gewijzigd door RickN op 25-08-2003 20:05 ]

[MSalters]

Yep. De voorstellen zijn voor mensen die FP willen gebruiken als het de beste gereedschap is voor de klus, maar toch de voordelen van C++ compilers willen hebben.

[AaroN]

Helemaal mee eens, het zal waarschijnlijk wel iets worden dat door slechts een klein deel van de proggers gebruikt zal worden... {hier stond larie}

[ Voor 30% gewijzigd door AaroN op 25-08-2003 21:52 ]

[farlane]

Wat ik jammer vind aan dit soort template trucjes in het algemeen (en ook aan deze specifiek, dus) is dat het het gebruik van C++ ontzettend ingewikkeld maakt.

Ik kan me daar goed in vinden. ( Maar ik ben dan ook geen C++ goeroe, en al helemaal geen C++ template goeroe )
Ik moet wel zeggen dat de specifieke voorbeelden die Sutter geeft ontzettend voor de hand liggen, en ik vind het er behoorlijk duidelijk uit zien.

Mensen die functioneel willen programmeren zullen dit doen in een echte functionele taal, mede door de inherent in zo'n taal aanwezige notationele schoonheid, en niet in een halfbakken, geforceerde oplossing in een willekeurige imperatieve taal.

Ik kan me voorstellen dat er voor een project gekozen is voor C++ ( om wat voor reden dan ook ) en dat er bij een specifiek probleem naar voren komt dat het op een fp wijze bijzonder clean en generiek op te lossen is.
Je zou de twee dan goed kunnen combineren.

[offtopic]
Wat me verder opvalt is dat als mensen het over fp hebben, dat het al snel gaat over parsers. Is het zo dat fp alleen geschikt is voor parsers, of komt dat omdat fp nog niet ( helemaal ) uit de academische sfeer is gehaald, en mensen in die richting daar gewoon vaak mee bezig zijn?

[mbravenboer]

farlane: Wat me verder opvalt is dat als mensen het over fp hebben, dat het al snel gaat over parsers. Is het zo dat fp alleen geschikt is voor parsers, of komt dat omdat fp nog niet ( helemaal ) uit de academische sfeer is gehaald, en mensen in die richting daar gewoon vaak mee bezig zijn?

Het heeft denk ik nog twee oorzaken (naast de reden die je zelf al noemt) :

1) Functionele talen zijn erg geschikt voor het maken van combinator libraries, waarbij je bijna een nieuwe taal creeert in de functionele taal. Parser combinators zijn een goed voorbeeld van parser combinator libraries.

2) Veel van de bezoekers die het hier over Haskell hebben studeren of hebben gestudeerd aan de Universiteit Utrect . Je leert daar in het 1e jaar functioneel programmeren en in het 2e jaar wordt deze kennis toegepast in de cursus grammaticas en ontleden, waarvoor parser combinator libraries worden gebruikt. Je leert er zelf niets over het bouwen van een parser in een imperatieve taal. Ook de introductie cursus in de compilerbouw is op de UU gebaseerd op functionele talen. Verder wordt de toepassing van een functionele taal niet direct ergens afgedwongen, waardoor er in overige vakken veel Java wordt gebruikt voor practica. Compiler (en parser) bouw lijkt zo dus vanuit de gegeven vakken de meest prominente toepassing van functionele talen.

[Verwijderd]

Ik lees nu bovenstaande voorbeelden, en ik zie eigenlijk helemaal niks wat C niet al lang had. Ben ik nou zo dom? Je kan functie-types toch gewoon typedefinieren ("typedef return_type (* type_naam) (type arg1, type arg2);") en die kun je per definitie al globaal aanroepen.

Lees ik nou zo erg over de voordelen/extra's van bovenstaande heen of ben ik gewoon compleet gek? .

_{(En dat dit stricte type-definities zijn boeit niet, dat is nou eenmaal zo bij C. Ik zie dat als een voordeel, anderen als een nadeel, die discussie is oeverloos...)}

[farlane]

Verwijderd schreef op 26 August 2003 @ 11:25:
Ik lees nu bovenstaande voorbeelden, en ik zie eigenlijk helemaal niks wat C niet al lang had.

Het verhaal gaat helemaal niet over C, maar over C++.

Bovendien, er staat ook dat een dergelijke functiepointer alleen werkt met de types die in het prototype genoemd staan.

std::function kan ook functies aan waarbij bv de argumenten impliciet te casten zijn. ( En het binden aan memberfuncties slaan we dan maar ff over )

[MSalters]

Er zijn twee belangrijke uitbreidingen: Ten eerste kan een functiepointer geen geassocieerde data hebben. Een functor kan dat wel. Bijvoorbeeld die functor (_1+1) is een unaire functie met als data de integer 1. Dit laat ook het tweede verschil zien; in C kun je dit soort functies niet run-time aanmaken.

[ Voor 3% gewijzigd door MSalters op 26-08-2003 12:22 ]

[mbravenboer]

MSalters: Ten eerste kan een functiepointer geen geassocieerde data hebben. Een functor kan dat wel. Bijvoorbeeld die functor (_1+1) is een unaire functie met als data de integer 1. Dit laat ook het tweede verschil zien; in C kun je dit soort functies niet run-time aanmaken.

Misschien is het aardig om dit te vergelijken met geneste functies in GCC. Als je goed weet wat je doet kan je daar vergelijkbare zaken mee doen omdat die ook lexicale scope hebben.

(voor mensen die deze 'feature' niet kennen is dit een aardige inleiding )