Les Closures en C (et donc Objective-C)
psychoh13
Mothership DeveloperMembre
Bonjour à tous, je vais vous présenter une nouveauté ajouté par Apple au langage C.
Apple a publié la gestion d'une nouvelle syntaxe dans les compilateurs GCC et surtout LLVM (je n'ai réussi à le faire marcher qu'avec celui-là ).
Donc les closures, appelées aussi blocks, sont des petits morceaux de code qui peuvent être passé d'une fonction à une autre et être appelée dans la fonction appelée. Elle permet notamment un remplacement des fonctions imbriquées qui ne sont pas très sécurisées dans GCC.
La syntaxe des blocks est surprenantes au début.
Pour déclarer une variable de type block, ça ressemble beaucoup à la syntaxe de déclaration d'un pointeur de fonction, il suffit de remplacer l'étoile '*' par un accent circonflexe '^' :
Le nom des paramètres n'est pas nécessaire dans la déclaration de la variable.
Exemple :
Cette ligne déclare une variable nommée monBlock, de type block, ne retournant rien et prenant en paramètre un entier et un char*.
Pour exécuter un block c'est comme une simple fonction :
Exemple :
C'est ici que ça se corse, voici la syntaxe complète :
Donc comme on peut le voir ici, on déclare la liste des arguments du block entre parenthèse entre l'accent circonflexe et l'accolade ouvrante, si le block n'a pas de paramètre, il n'est pas utile de mettre cette partie-là .
Ensuite dans le block, on peut avoir une liste de variables séparées par des virgules entre deux pipes '|' (le signe pour le OU logique ou bit-à -bit), ces variables sont des variables disponibles dans la fonction dans laquelle est déclarée le block. Déclarées des variables dans cette partie-là donne accès à celles-ci dans le code du block, ce qui est très avantageux, on le verra plus tard.
Enfin, la partie du code du block, là c'est du code tout ce qu'il y a de plus normal, on a accès aux paramètres déclarées pour le block et à la liste des variables entre les barres verticales.
Alors, il y a déjà deux questions à ce poser ici :
Si notre block retourne une valeur comment donne-t-on son type ?
Et bien ici c'est assez bizarre, en fait le compilateur utilisera le type de la variable utilisé dans l'instruction "return".
Par exemple si j'écris : "return 5;" mon block retournera un "int", en revanche, si j'écris "return (char)5;" alors mon block retournera un "char".
La deuxième question concerne la liste des variables de la fonction appelante... Celle qu'on donne entre les barres verticales. Est-ce que les changements appliqués à ces variables se répliquent dans la fonction où a été déclaré le block ?
Et bien normalement c'est illégal, la valeur devrait être copiée, pour l'instant cela reste ambiguë. En effet, le problème proviendrait du fait que si on utilise le block hors de la fonction où il a été défini, c'est-à -dire qu'on utilise le block alors que la fonction n'existe plus, on ne devrait plus avoir accès aux variables disponibles. Cependant un mécanisme de références, et de comptage de références pour les blocks, permet de sortir le block et les variables qu'il utilise de la fonction et de les allouer dans le tas et non plus dans la pile comme c'est le cas par défaut.
Il semblerait même que la syntax "| x |" soit abandonnée. En fait, il ne sera pas nécessaire de dire au block quelles sont les variables de la fonction parente auxquelles il a accès. Il sera par contre interdit de modifier ces variables, à moins qu'on déclare ces variables comme étant "__byref" dans la fonction parente.
Exemple :
Voilà je pense avoir fait le tour de la syntaxe.
Je parlerai des avantages dans un autre post.
Apple a publié la gestion d'une nouvelle syntaxe dans les compilateurs GCC et surtout LLVM (je n'ai réussi à le faire marcher qu'avec celui-là ).
Donc les closures, appelées aussi blocks, sont des petits morceaux de code qui peuvent être passé d'une fonction à une autre et être appelée dans la fonction appelée. Elle permet notamment un remplacement des fonctions imbriquées qui ne sont pas très sécurisées dans GCC.
La syntaxe des blocks est surprenantes au début.
Pour déclarer une variable de type block, ça ressemble beaucoup à la syntaxe de déclaration d'un pointeur de fonction, il suffit de remplacer l'étoile '*' par un accent circonflexe '^' :
typeDeRetour (^nomDeLaVariable)(typeParam1 nomParam1, typeParam2 *nomParam2, ...);
Le nom des paramètres n'est pas nécessaire dans la déclaration de la variable.
Exemple :
void (^monBlock)(int, char *);
Cette ligne déclare une variable nommée monBlock, de type block, ne retournant rien et prenant en paramètre un entier et un char*.
Pour exécuter un block c'est comme une simple fonction :
nomDeLaVariable(param1, param2, ...);
Exemple :
monBlock(5, "chaine");
C'est ici que ça se corse, voici la syntaxe complète :
^(typeParam1 nomParam1, typeParam2 nomParam2, ...){ | listeDeVariables | code_du_block };
Donc comme on peut le voir ici, on déclare la liste des arguments du block entre parenthèse entre l'accent circonflexe et l'accolade ouvrante, si le block n'a pas de paramètre, il n'est pas utile de mettre cette partie-là .
Ensuite dans le block, on peut avoir une liste de variables séparées par des virgules entre deux pipes '|' (le signe pour le OU logique ou bit-à -bit), ces variables sont des variables disponibles dans la fonction dans laquelle est déclarée le block. Déclarées des variables dans cette partie-là donne accès à celles-ci dans le code du block, ce qui est très avantageux, on le verra plus tard.
Enfin, la partie du code du block, là c'est du code tout ce qu'il y a de plus normal, on a accès aux paramètres déclarées pour le block et à la liste des variables entre les barres verticales.
Alors, il y a déjà deux questions à ce poser ici :
Si notre block retourne une valeur comment donne-t-on son type ?
Et bien ici c'est assez bizarre, en fait le compilateur utilisera le type de la variable utilisé dans l'instruction "return".
Par exemple si j'écris : "return 5;" mon block retournera un "int", en revanche, si j'écris "return (char)5;" alors mon block retournera un "char".
La deuxième question concerne la liste des variables de la fonction appelante... Celle qu'on donne entre les barres verticales. Est-ce que les changements appliqués à ces variables se répliquent dans la fonction où a été déclaré le block ?
Et bien normalement c'est illégal, la valeur devrait être copiée, pour l'instant cela reste ambiguë. En effet, le problème proviendrait du fait que si on utilise le block hors de la fonction où il a été défini, c'est-à -dire qu'on utilise le block alors que la fonction n'existe plus, on ne devrait plus avoir accès aux variables disponibles. Cependant un mécanisme de références, et de comptage de références pour les blocks, permet de sortir le block et les variables qu'il utilise de la fonction et de les allouer dans le tas et non plus dans la pile comme c'est le cas par défaut.
Il semblerait même que la syntax "| x |" soit abandonnée. En fait, il ne sera pas nécessaire de dire au block quelles sont les variables de la fonction parente auxquelles il a accès. Il sera par contre interdit de modifier ces variables, à moins qu'on déclare ces variables comme étant "__byref" dans la fonction parente.
Exemple :
int x;<br />int __byref y;<br />int (^monBlock)(int) = ^(int var){<br /> x = var; // erreur : la variable est read-only<br /> y = var; // fonctionne<br /> return x * y + var; // fonctionne<br />};
Voilà je pense avoir fait le tour de la syntaxe.
Je parlerai des avantages dans un autre post.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Les avantages d'un tel système c'est de permettre notamment de déclarer du code sans créer de nouvelles fonctions et de le passer à une autre fonction pour qu'elle l'utiliser.
ç'a en plus l'avantage, comme on l'a vu plus haut, de donner accès aux variables de la fonction dans laquelle est déclaré le block.
À l'heure actuelle, pour obtenir le même effet, on est obligé de passer une variable "context" dans le callback d'une telle fonction pour pouvoir avoir, depuis l'appel à notre fonction, accès à des informations auxquelles on a pas directement accès par la fonction qui appelle.
Par exemple, pour trier des objets dans un CFMutableArray de chez Apple, nous utilisons cette fonction :
Ce sont les deux derniers paramètres que les blocks cherchent à remplacer par un seul. Nous pouvons voir notre context, et la fonction de comparaison qui doit être déclarée ainsi :
Lorsque le CFArray veut comparer deux variables, la fonction va appeler notre callback en lui passant les deux variables qu'il veut comparer et le context, c'est-à -dire la structure qu'on a passé à la fonction de tri à l'origine. Dans ce context on peut mettre tout information qui pourrait influencer notre tri, par exemple on peut y mettre un objet sur lequel appeler une méthode qui traitera à son tour les deux variables.
C'est une syntaxe plutôt gênante, non seulement on a besoin de déclarer une fonction à part mais en plus il faut qu'on crée une structure spécifique pour donner accès à des valeurs importantes pour notre fonction.
L'avantage des blocks par rapport à ça, c'est justement de ne pas avoir besoin de structure spécifique pour accéder à des valeurs, il suffit simplement que les variable existent dans la fonction dans laquelle est déclarée le block, elles sont ensuite rendues disponible lors de l'appel et leur valeur correspond à celles qui a été donnée dans la fonction parente du block.
N'est-ce pas merveilleux ?
Donc maintenant, au lieu d'avoir une fonction de comparaison comme celle-ci :
on aura un block défini comme ça :
On a aussi un autre avantage tout aussi enviable avec les blocks lorsqu'il s'agit d'itération.
Avant, quand on voulait itérer dans un NSArray par exemple, nous étions obligés de procéder de la sorte :
C'est une technique très simple et pas très optimisée, elle a tout de même pour avantage de fournir dans le for() l'index de l'objet.
Apple, avec Objective-C 2.0, a cherché a optimisé les itérations avec un foreach() bien à eux :
Ici, on perd l'index de l'objet, mais au moins l'itération est très optimisée car sous le capot le foreach() n'envoie pas un message pour récupérer un objet, mais en général un message pour récupérer plusieurs dizaines d'objets.
Il est aussi possible d'utiliser ce système avec un NSDictionary :
Là , même si on optimise la récupération des clés, la récupération des objets se fait là aussi un par un ce qui n'est pas bon pour l'optimisation.
C'est là que les blocks montrent leur puissance : dans les itérations.
Pour itérer dans une collection, on donnera à une méthode spécifique, le block de code que l'on souhaite lui faire exécuter, en clair on va lui passer le code entre les accolades du for().
Et ce sera à la méthode appelée de gérer ce qui va être envoyé au block pour être exécuté.
Par exemple, pour un NSArray, on pourra avoir un block avec pour type :
Comme le suggère le typage du block, la méthode d'itération passera au block non seulement l'objet en cours mais aussi son index, ce qui permettra une gestion plus fine des objets, on pourra avoir exactement le même effet que le premier exemple :
On a donc un double avantage, non seulement on sait précisément quel objet est passé et à quel point on est, mais en plus comme on passe le block de code à une méthode, en interne beaucoup d'optimisation peuvent être possible, ce qui rendra l'itération extrêmement rapide et efficace.
Maintenant, regardons notre exemple des dictionaires, on a vu plus haut que pour avoir la clé et la valeur attachée à cette clé, il était nécessaire d'itérer sur les clés et de récupérer l'objet que la clé indique. Et bien voilà ce qu'on peut avoir comme block pour régler ce problème :
De la même manière que pour le NSArray, ici la fonction d'énumération passera au bloc la clé et son objet attaché SIMULTANà‰MENT ce qui est très très avantageux, on peut imaginer toute sorte d'optimisation en arrière-plan, rendant l'itération dans un dictionaire toujours plus efficace.
Pour avoir le même effet que l'exemple plus haut nous pourrions faire comme ça :
Encore une fois ça laisse rêveur.
Maintenant on va voir un petit exemple qui allie l'itération et l'utilisation de variable existante dans la fonction parente :
Après l'exécution de la méthode, le NSArray "unSurDeux" contiendra tous les objets pairs de "myArray".
Neat isn't ?
Cependant, il est possible de les tester aujourd'hui en téléchargeant et compilant les dernières version de LLVM et LLVM-GCC-4.2, la procédure pour compiler correctement et tester les blocks est expliquée dans le dossier de LLVM-GCC dans le fichier "README.LLVM".
Malheureusement, compiler LLVM-GCC de cette manière ne permet pas d'utiliser le compilateur avec Xcode pour pouvoir compiler des applications Cocoa correctement.
La technique de compilation d'Apple qui permet d'obtenir un LLVM compatible avec Xcode nativement n'est pas faisable, apparemment, sans les outils réservés aux employés d'Apple. Certaines options sont différentes et nécessitent donc de créer un fichier de configuration spécifique à ce LLVM... Ce que je n'ai pas encore réussi à faire.
PS : Ces posts ne vont pas à l'encontre d'une quelconque NDA, à part peut-être la première phrase de ce post-ci, mais le reste est disponible au public notamment sur llvm.org.
Penses-tu que cette innovation des blocks puisse rentrer à terme dans le C standard ?
Mais bon, déjà il est intégré à llvm et gcc donc il peut-être utilisé n'importe où.
As-tu tenter d'essayer par toi-même ?
Non mais ton explication est très claire.
On sent bien le potentiel d'optimisation qu'il y là dessous, et en même temps cela correspond aussi à des moments de codage où on s'est dit "la barbe, on l'a déjà fait".
Faire une macro c'est toujours un peu tordu, une fonction static inline pose le pensum du passage des arguments, et les boucles foreach où on peut avoir besoin à la fois de l'objet, de l'index/clé c'est ultra-courant. Cela répond sans doute à un vrai besoin.
On utilise comme collection les tableaux passés en paramètre de main :
Ce code affichera dans la console les paramètres passés au programme ainsi que les variables d'environnement.
Tu mets une option pour compiler ? j'ai essayé gcc-4.2 pgm.c -o pgm -Wall -Wextra mais il n'accepte pas le ^
J'ai téléchargé LLVM grâce à cette commande : "svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm"
Ainsi que llvm-gcc avec celle-ci : svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk dst-directory
La procédure est plus ou moins bien décrite dans le fichier README.LLVM dans gcc-llvm-4.2. Il faut compiler llvm avec en option de la commande make : "make ENABLE_OPTIMIZED=1".
Ensuite tu crées la variable d'environnement $LLVMOBJDIR qui va contenir le dossier où a atterri l'application LLVM compilée et ses copines.
Ensuite le reste c'est suffisamment bien expliqué, il faut que tu crées des variables d'environnement à chaque fois que tu vois quelque chose d'écrit en majuscules suivi d'un égal.
Et aussi la version de Darwin sous Leopard c'est censé être la 9.
J'ai galéré pour faire tout ça. lol
/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
et
/Developer/usr/llvm-gcc-4.2/bin/i686-apple-darwin9-llvm-gcc-4.2
% /Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 pgm.c -o pgm
...
error: expected ‘)' before ‘^' token
idem avec l'autre binaire
Je n'ai pas trouvé le man
Je relance pour la n-ième fois le sujet... Pour vous annoncer la découverte de deux documents publiés par Apple, depuis déjà un certain temps, sur les spécifications de l'extension des blocks dans le langage ainsi que de l'implémentation de ceux-ci.
Voici les liens :
Language specs
Implementation specs
Le premier ne dit pas vraiment plus que ce ce que je dis dans le reste du sujet.
En revanche, le deuxième donne des informations très intéressantes sur comment est implémenté ce système, et aussi sur comment le compilateur interprète les blocks pour construire des structures permettant de les utiliser.
Grâce à ce document, on en sait plus sur le fonctionnement du runtime des blocks, qui est constitué de deux fonctions permettant la copie des structures représentant les blocks depuis la pile vers le tas. Ce système permet l'utilisation de ces structures à l'extérieur du context dans lequel elles ont été créé tout en conservant la valeur des variables capturées dans ce context.
C'est à partir de ce document que j'ai écrit mon propre runtime permettant l'utilisation des blocks avec la plupart des fonctionnalités qu'ils proposent.
Mon runtime permet aux blocks de recevoir des messages à la manière d'objet Objective-C et il permet de copier les blocks sur le tas pour les utiliser à l'extérieur du context de création.
Il vous est possible, grâce au compilateur Clang, d'utiliser cette fonctionnalité de manière transparante dans vos projets actuels pour Leopard. Vous pouvez suivre les instructions que je donne dans le README.txt du répertoire de mon code. Le runtime est sous license MIT, la moins contraignante des licenses open-source, vous pouvez donc l'utiliser sans problème.
Voici le lien du répertoire : http://github.com/PsychoH13/C-ObjC-Blocks/
N'hésitez pas à me poser des questions, où à faire des commentaires. Merci.
Mais c'est certainement parce que c'est nouveau pour moi
En tout cas, ça à l'air fort prometteur.
Mais sinon elle est largement inspirée des pointeurs de fonctions, et puis l'accent circonflexe c'est en quelque sorte le nom de la fonction qu'un block, étant anonyme, ne peut avoir.
Je reprends le code de Psycho quelques posts ci-dessus
je compile avec la version par défaut de gcc
J'exécute
Impec
Par contre tu peux virer le void *_NSConcreteStackBlock; au début du fichier, ça devrait marcher sans.
De plus normalement pour que les blocks fonctionnent il faudrait utiliser l'option -fblocks.
C'est beau comme une crèche, .... je mate
Ok
A l'essai, cela devient utile si on met -std=c99, par exemple pour faire une déclaration locale de variable de boucle : for(int i=0;...;...)
Par contre je ne vois pas trace de -fblocks dans le man ?
Sinon, sous SL, tu peux rajouter /Developer/usr/bin dans ton path pour avoir accès direct depuis la console à Clang et LLVM-GCC.
Dans ton fichier ~/.bash_login tu rajoutes :
Par contre perso pour rendre ton code plus lisible Philippe je mettrais un typedef sur ton type de block : Juste histoire de monter qu'on peut typedef-er les blocks (comme on peut le faire avec les pointeurs de fonctions) et qu'à mon goût ça rend la chose encore plus lisible (et appréhendable pour qqun qui ne connais pas la syntaxe des blocks et à qui cette surcharge syntaxique de partout pourrait faire peur :P)
Au passage, dans Xcode 3.2, lorsque vous taper le nom d'une méthode contenant des blocks en paramètres, vous avez les espaces dédiés au paramètre entre lesquels vous pouvez circuler, mais en plus si vous appuyer sur enter sur la paramètre de type block il créera un block vide dont le type est adapté au paramètre !!! En revanche ça ne marche pas si c'est un typedef, par exemple avec NSComparator ça marchera pas...
Bien vu pour l'autocomplétion des blocs dans Xcode, trop fort :P
Par contre dommage que ça ne fonctionne pas pour les typedefs, qui sont pourtant bien pratique pour éclaircir la compréhension du code (comme le montre mon remaniement de ton code ou l'utilisation de NSComparator chez Apple) et que perso dans le cas des pointeurs de fonctions ou des blocks, j'utilise tout le temps plutôt que la "version longue"... zut.
Enfin quoique "pour les autres pas vraiment", ça dépend, enfin ça se discute
Moi question lisibilité, à part si j'utilise ledit bloc (ou pointeur de fonction) juste une fois dans mon code, maxi 2 mais pas plus, je trouve qd mm plus clair et lisible d'avoir un typedef pour définir ce pointeur de fonction ou ce block... surtout si ça commence à être un pointeur de fonction ou bloc avec pas mal d'arguments et des pointeurs partout, fastidieux à réécrire à chaque fois pour la déclaration des variables de ce type ou des prototypes des fonctions qui prennent ces blocks / PdF en paramètres.
Parce que bon, imagine que dans ton code tu aies 3 fonctions prennant en paramètre un block ayant pour signature : Bon évidemment j'exagère, mais bon tu vois le truc, ça peut commencer à faire long... Car là je n'ai mis que la déclaration de variable, mais après si ce n'est qu'un type de block à passer en tant qu'un argument (potentiellement parmi d'autres) à une fonction... Ca commence à faire long !
Et puis même si ce n'est qu'une variable, là je n'ai fait que la déclarer, mais après s'il faut l'affecter c'est pas mieux :
Pfiou ! Alors qu'avec des typedefs, ça donnerait : ça donne déjà plus sympa à la lecture, non ? :P
Bon bien sûr tu ne rencontres pas tous les jours des signatures de blocks aussi alambiquées et prise de tête, je te le concède sans problème. Encore moins des blocks prenant lui-mm des blocks en paramètre.
Et encore que ça m'est déjà arrivé (enfin avec des pointeurs de fonction, mais bon) dans un de mes projets, où j'avais une architecture pas mal basée sur les plugins et pointeurs de fonction.
Mais bon après là c'est juste pour mettre en avant avec un cas extrême que parfois ça peut avoir une syntaxe super lourde, alors que si tu transformes ça avec des typedefs c'est bien plus lisible
Oh et puis surtout, je trouve ça plus lisible d'avoir le nom de variable à la fin, pour retrouver une syntaxe similaire à [tt]int n[/tt] dans [tt]TypeBlock1 myBlock[/tt], alors que sans typeDef le nom de variable est coincé en plein milieu de la ligne de déclaration, je trouve ça moyen côté cohérence comme côté lisibilité
Bon après chacun ses habitudes de codage. Et pour un bloc qui prend juste un int et un char*, ça reste raisonnable de ne pas utiliser de typedef, mais bon, fait pas aller bcp plus loin dans les types d'arguments quoi.
Par contre j'aimerais demander votre avis sur la disposition du code. Je suis pour ma part intransigeant sur la déclaration de tous les prototypes dans un code C, n'acceptant pas la disposition
mais imposant :
Quelle est votre position sur le sujet ? (étant bien entendu que pour le code de ce post, on s'en fout)
1) En tant que professionnel, comptez-vous utiliser beaucoup cette option, et quelles situations standards d'utilisation vous viennent à l'esprit ?
2) Est-ce que cela est disponible de base dans les autres systèmes UNIX ?
3) En clair, un enseignement C de bonne qualité doit-il à terme inclure les blocks ?
En effet, le fait de ne pas créer de prototype te force à déclarer toutes les fonctions avant qu'elles soient utilisées, déjà si A appelle B et B appelle A ça se pose un gros problème pour l'ordre qui est tout simplement impossible à trouver. Mais au-delà de ça, ça te force surtout à ordonner tes fonctions dans l'ordre d'utilisation et non pas dans un ordre plus logique que serait l'importance de la fonction ou le groupement de fonctions par type ou par tâche. Et au final tu te retrouves avec la fonction d'entrée du programme main() à la fin de ton fichier ! Alors qu'en général on suppose que l'entrée est au début.
Donc pour moi, on déclare les prototypes de fonctions au début du fichier pour dire "voilà toutes les fonctions utilisées dans ce programme" puis on définit le main pour dire "voilà comme marche le programme" et enfin on définit les autres fonctions pour dire "voilà comment chaque fonction est définie" et bien sûr on les met dans un ordre permettant une meilleure lisibilité.
Et pour finir, le fait de déclarer les prototypes avant et les définitions après permet, pour les débutants, d'introduire plus facilement le concept de programmation modulaire et d'en-tête. En effet, comme les en-têtes ne contiennent que des déclarations de types et de fonctions utiles pour utiliser une API, ces en-têtes sont inclus en début de fichier, alors que les fichiers de définitions de fonctions sont compilés à part.
Cependant, la première technique peut avoir un aspect pédagogique pour montrer comme fonctionne le compilateur C surtout en ce qui concerne les ordres d'apparition.
1) Mon boulot, pour l'instant, se situe essentiellement dans le monde mac, bon je dois encore développer pour Leopard, donc pas de blocks à priori (bien qu'il existe un runtime pour leopard, qui est inspiré d'un runtime que j'avais fait d'ailleurs), cependant, dès que je ne développerai plus que pour Snow Leopard et au-delà je ne ferai qu'utiliser les blocks. Tout simplement parce qu'ils améliorent la lisibilité du code et qu'ils vont permettent aux implémenteurs du code qui les utilise (Apple par exemple) d'améliorer les performances facilement sans détruire notre code.
2) Les compilateurs Clang et LLVM-GCC qui sont open-source définisse les blocks et sont utilisables partout, donc sur Unix, les spécifications du langage, le runtime et les spécifications du runtime sont tout autant Open Source donc utilisable partout et notamment sur Unix. De plus, je sais que le projet BSD va petit à petit changer de compilateur principal et passer à Clang pour se débarrasser de GCC ce qui va mettre les blocks pratiquement en standard sur cette plateforme.
Il faut aussi ajouter que le projet GNUStep, en partie grâce à moi, intègre déjà un runtime pour les blocks et va lui aussi petit-à -petite passer à Clang car avec celui-là ils sont sûrs qu'ObjC sera toujours soutenu par le compilateur, alors qu'il est abandonné dans la branche principale de GCC.
3) Maintenant, pour ce qui est d'enseigner l'existence des blocks. Moi je dirais OUI, ne serait-ce que pour inciter les gens à vouloir les utiliser et ainsi les mettre en standard de facto. Peut-être au début tu mets les blocks en extra, indiquant qu'ils existent, comment on les utilise, les avantages et inconvénients, mais genre pour les personnes qui voudraient en savoir plus.
Mais une nouvelle technologie ne peut réellement s'imposer que si les gens en parlent (dans le milieu concerné bien sûr), donc c'est toujours bon d'en parler à des débutants C, vers la fin car il s'agit d'un concept plutôt complexe mais surtout avec des cas critiques difficilement soupçonnable.
D'un autre côté, les blocks ont été conçues d'une telle manière qu'ils ne détruisent en rien le C lui-même ; certes il s'agit d'une nouvelle syntaxe, mais elle n'a pas plus d'effet sur le C que la syntaxe d'envoi de messages d'ObjC, c'est-à -dire qu'il est tout à fait de reproduire ce que fait la syntaxe du block en C pur et que cette syntaxe n'est qu'une simplification. Ce qui fait qu'on se retrouve avec les mêmes cas limites qu'en C pur (notamment niveau portée des variables), et donc apprendre comment fonctionnent les blocks ainsi que ses cas limites peut aider les débutants à mieux comprendre certains aspects obscures et méconnus du C.
Exemple : "Pourquoi ce code ne marche pas ?":
Donc selon moi, les blocks sont une bonne chose à apprendre, non seulement pour les répandre mais aussi pour comprendre encore mieux le C.