J'espère que ce qu'ils considèrent être de la programmation fonctionnelle est autre chose que des immondices illisibles (et accessoirement indébuguable, je parle d'expérience... :/ ) à base de templates qui nécessitent l'emploi d'adaptateurs dans tous les sens pour des raisons techniques dont ne devrait surtout pas se soucier le développeur (ex: mem_fun)
histoire de fixer les idées, voici ce qu'on peut lire dans GnuGK :
(où pour couronner le tout InternalFind est bien sûr lui même une template)
ce qui signifie à peu près, dans un langage intelligible par un être humain normal et sans à avoir à apprendre des foisons de symboles supplémentaires :
Bref si ça progresse vers quelque chose de moins sataniste que l'exemple cité ci-dessus, c'est une bonne chose. Sinon il faudrait mieux interdire aux gens de faire du mauvais fonctionnel inutile en C++, car ce n'est pas maintenable par quelqu'un qui ne passe pas sa vie à étudier ce langage et ses "subtilités" (pour rester poli).
En passant l'emploi d'une approche pseudo fonctionnelle et donc d'une syntaxe aussi biscornue ne se justifiait absolument pas ici en pratique, une boucle avec un return quand l'élément est trouvé aurait été bien plus compréhensible, maintenable et débuguable.
La syntaxe et la nécessité de compenser des faiblesse structurelles du langages (mem_fun + besoin de noter explicitement H225_EndpointIdentifier, sans même parler de l'opérateur == qui visuellement n'est plus repérable) disqualifie donc en pratique une approche qui pourtant peut être considérée comme conceptuellement supérieure.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Guillaume Knispel . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 7.
histoire de fixer les idées, voici ce qu'on peut lire dans GnuGK :
return InternalFind(compose1(bind2nd(equal_to<H225_EndpointIdentifier>(), epId),
mem_fun(&EndpointRec::GetEndpointIdentifier)));
(où pour couronner le tout InternalFind est bien sûr lui même une template)
ce qui signifie à peu près, dans un langage intelligible par un être humain normal et sans à avoir à apprendre des foisons de symboles supplémentaires :
return InternalFind(lambda x: (x.GetEndpointIdentifier() == epId))
Bref si ça progresse vers quelque chose de moins sataniste que l'exemple cité ci-dessus, c'est une bonne chose. Sinon il faudrait mieux interdire aux gens de faire du mauvais fonctionnel inutile en C++, car ce n'est pas maintenable par quelqu'un qui ne passe pas sa vie à étudier ce langage et ses "subtilités" (pour rester poli).
En passant l'emploi d'une approche pseudo fonctionnelle et donc d'une syntaxe aussi biscornue ne se justifiait absolument pas ici en pratique, une boucle avec un return quand l'élément est trouvé aurait été bien plus compréhensible, maintenable et débuguable.
La syntaxe et la nécessité de compenser des faiblesse structurelles du langages (mem_fun + besoin de noter explicitement H225_EndpointIdentifier, sans même parler de l'opérateur == qui visuellement n'est plus repérable) disqualifie donc en pratique une approche qui pourtant peut être considérée comme conceptuellement supérieure.