De plus, rien ne t'empêches de définir ton compteur entre les directives @interface et @end de ta classe (après les accolades, puisque tu peux pas définir de variable d'instance statiques), il t'avertira que ta variable compteur n'est pas utilisée mais en fait elle le sera. Voire tu peux même les définir entre les directives @implementation et @end et en plus tu auras un warning de moins.
Effectivement, après les accolades ça fonctionne ; ça revient au même que de la mettre en dehors des dites directives... Mais du coup (en mettant de côté le fait que c'est assez laid de la définir à cet endroit), ça fournit une variable statique à tous les fichiers de sources qui incluent ce header !
Par contre, en faisant des tests, je suis tombé sur un truc pas banal... Apparemment on peut définir des variables "static" locales qui n'interfèrent pas avec les globales du même nom et avec même un type différent...
static int test = 0;<br /><br />int main(int argc,char *argv[])<br />{<br />Â static float test = 1.;<br />Â return 0;<br />}
Ca ne me paraà®t pas très logique tout ça... ???
PS : les avertissements "defined but not used" que l'on a lorsqu'on la déclare dans le .h au lieu de la déclarer dans le .m, c'est justement ceux qui proviennent des autres fichiers incluant le .h et qui n'utilisent pas la variable statique !
De retour de weekend, j'ai lu les différents posts ci-dessus. Les variables de classe existent en C++ mais pas en Objective-C, C'est écrit dans tout les bouquins sur Obj-C. Mon problème initial est un problème de fainéantise! Le voulais écrire en un coup une structure et son initialisation sans passer par des tas d'affectations de valeurs. Comme l'initialisation ne marche pas entre le {} de @interface je l'ai mis en dehors. Mais comme je souhaite travailler avec des NSSTring j'ai modifier la structure et j'ai écris:
Bah si c'est tout à fait logique au contraire, c'est simplement une définition d'une nouvelle variable dans un sous-bloc :
int i = 0;<br />void fonction(void)<br />{<br />Â Â int i = 1;<br />Â Â {<br />Â Â Â Â int i = 2;<br />Â Â Â Â {<br />Â Â Â Â Â Â int i = 3;<br />Â Â Â Â Â Â printf("i = %d\n", i);<br />Â Â Â Â }<br />Â Â Â Â printf("i = %d\n", i);<br />Â Â }<br />Â Â printf("i = %d\n", i);<br />}
ça t'affichera 3, 2, 1... Donc tes variables statiques seront strictement restreintes aux blocs dans lesquels elles sont définies.
Oui, bien sûr, pour des variables automatiques ça me paraà®t tout à fait logique ! C'est dans le cadre de la définition de "static" que ça me paraà®t illogique...
Si une variable "static" est valable dans toute l'unité de compilation, comment se fait-il que l'on puisse dans la même unité de compilation en définir deux de même nom et de type différent, et qui ont des valeurs indépendantes ? C'est ça qui me choque...Â
PS : en pratique, je n'ai jamais utilisé le mot-clé "static" ailleurs que dans le cadre de fonctions virtuelles pures en C++ ; comme j'ai pas revu la théorie C depuis un bail, ça m'échappe un peu... Il faudrait que je replonge le nez un peu dans Kernighan et Ritchie :P
Bon, ça fait un bail que j'ai quitté l'école et la théorie, et je me sens un peu largué sur les définitions et les utilités de ces différentes classes de variables :crackboom:- ;D (que je n'utilise jamais en fait... ???)
En tout cas, apparemment la visibilité des variables "static" est plus limitée que celle des variables "auto", puisque si on utilise des variables "auto" de même nom dans 2 fichiers en dehors des blocs {}, ça pose problème au lien. Pourtant, les "auto" ont aussi une visibilité "locale", mais elle dépasse sans doute les frontières des fichiers.Â
[Edit] Ah, je crois me souvenir qu'il faut utiliser "extern" pour voir la variable "auto" d'un autre fichier...
Tu vois que tu crées des constantes statiques pour qu'elles vivent encore après la fin de la fonction et tu en transmets l'adresse à une autre fonction pour pouvoir l'utiliser dans ton dégradé. C'est comme ça qu'on faisait les dégradés avant Leopard.
PS : c'est extrait de la documentation d'Apple sous Tiger (Painting an Axial Shading), ça te crée un dégradé allant du noir vert le magenta.
Bon, c'est bien beau tout ça, mais au final... ça sert dans quelles situations ? :P
En cours, je vends cette notion avec le calcul paresseux : La suite de Fibonacci u(n+2)=u(n+1)+u(n) est une cata si on la programme récursivement (en 2^n). Par contre, si on stocke à chaque récursion les nouvelles valeurs calculées à l'aide d'un tableau défini statiquement, ainsi que le rang n de la dernière valeur connue, on trouve au prix d'un encombrement mémoire, un algorithme linéaire.
Ah ouais... Effectivement, l'exemple des dégradés me dit quelque-chose ; j'en avais bouffé avec DxO Optics Pro pour faire des dégradés dans des bezierPath... Faudrait que je regarde si on avait utilisé des "static"Â
Quant à calculer récursivement le n-ième terme de la suite de Fibonacci, effectivement c'est une drôle d'idée ;D J'imagine que ça se présente de cette manière :
#include <stdio.h><br />#include <stdlib.h><br /><br />unsigned long long fibo(unsigned long i);<br /><br />int main(int argc,char *argv[])<br />{<br />Â printf("%llu\n",fibo(40));<br />Â return 0;<br />}<br /><br />unsigned long long fibo(unsigned long i)<br />{<br />Â static unsigned long long fib[101] = {0};<br />Â if(i>100) {<br />Â Â printf("Erreur !\n");<br />Â Â exit(1);<br />Â }<br />Â if(i==0)<br />Â Â return 0;<br />Â else if(i==1)<br />Â Â return 1;<br />Â else {<br />Â Â if(fib[i]==0)<br />Â Â Â fib[i] = fibo(i-1)+fibo(i-2);<br />Â Â return fib[i];<br />Â }<br />}
Ceci-dit, on peut le faire aussi avec une variable "auto" en dehors du scope des fonctions... Peut-être moins propre et moins rapide, vu que les "static" ne sont pas sur la pile.
Réponses
Effectivement, après les accolades ça fonctionne ; ça revient au même que de la mettre en dehors des dites directives... Mais du coup (en mettant de côté le fait que c'est assez laid de la définir à cet endroit), ça fournit une variable statique à tous les fichiers de sources qui incluent ce header !
Par contre, en faisant des tests, je suis tombé sur un truc pas banal... Apparemment on peut définir des variables "static" locales qui n'interfèrent pas avec les globales du même nom et avec même un type différent...
Ca ne me paraà®t pas très logique tout ça... ???
PS : les avertissements "defined but not used" que l'on a lorsqu'on la déclare dans le .h au lieu de la déclarer dans le .m, c'est justement ceux qui proviennent des autres fichiers incluant le .h et qui n'utilisent pas la variable statique !
ça t'affichera 3, 2, 1...
Donc tes variables statiques seront strictement restreintes aux blocs dans lesquels elles sont définies.
C'est ce que je vous disais dans mon dernier post.
En C, la notion de statique est définie par la visibilité (locale) et la durée de vie (globale)
Les variables de classe existent en C++ mais pas en Objective-C, C'est écrit dans tout les bouquins sur Obj-C.
Mon problème initial est un problème de fainéantise! Le voulais écrire en un coup une structure et son initialisation sans passer par des tas d'affectations de valeurs.
Comme l'initialisation ne marche pas entre le {} de @interface je l'ai mis en dehors. Mais comme je souhaite travailler avec des NSSTring j'ai modifier la structure et j'ai écris:
Je n'ai pas d'erreur à la compilation. Mais si j'essaie de récupérer un nom:
ça ne marche pas !
Bien sur je vais faire autrement, mais j'aimerais bien savoir pourquoi ça ne marche pas. J'obtiens comme valeur: "invalide".
NSSTring au lieu de NSString...
Oui, bien sûr, pour des variables automatiques ça me paraà®t tout à fait logique !
C'est dans le cadre de la définition de "static" que ça me paraà®t illogique...
Si une variable "static" est valable dans toute l'unité de compilation, comment se fait-il que l'on puisse dans la même unité de compilation en définir deux de même nom et de type différent, et qui ont des valeurs indépendantes ?
C'est ça qui me choque...Â
PS : en pratique, je n'ai jamais utilisé le mot-clé "static" ailleurs que dans le cadre de fonctions virtuelles pures en C++ ; comme j'ai pas revu la théorie C depuis un bail, ça m'échappe un peu... Il faudrait que je replonge le nez un peu dans Kernighan et Ritchie :P
En tout cas, apparemment la visibilité des variables "static" est plus limitée que celle des variables "auto", puisque si on utilise des variables "auto" de même nom dans 2 fichiers en dehors des blocs {}, ça pose problème au lien. Pourtant, les "auto" ont aussi une visibilité "locale", mais elle dépasse sans doute les frontières des fichiers.Â
[Edit] Ah, je crois me souvenir qu'il faut utiliser "extern" pour voir la variable "auto" d'un autre fichier...
Effectivement, visibilité "locale", on ne la voit pas ailleurs ; durée de vie globale, à chaque nouvelle instance, elle s'incrémente.
Bon, c'est bien beau tout ça, mais au final... ça sert dans quelles situations ? :P
Bon c'est pas un bon exemple cette méthode, parce qu'il est plus propre d'utiliser : +class :
C'est aussi utiliser pour déclarer des structures qu'on va transmettre à une fonction, comme dans le cas des dégradés.
Des "dégradés" ? Là je veux bien un exemple
Et voici la fonction pour créer la fonction qui va dessiner le dégradé :
Tu vois que tu crées des constantes statiques pour qu'elles vivent encore après la fin de la fonction et tu en transmets l'adresse à une autre fonction pour pouvoir l'utiliser dans ton dégradé.
C'est comme ça qu'on faisait les dégradés avant Leopard.
PS : c'est extrait de la documentation d'Apple sous Tiger (Painting an Axial Shading), ça te crée un dégradé allant du noir vert le magenta.
En cours, je vends cette notion avec le calcul paresseux :
La suite de Fibonacci u(n+2)=u(n+1)+u(n) est une cata si on la programme récursivement (en 2^n).
Par contre, si on stocke à chaque récursion les nouvelles valeurs calculées à l'aide d'un tableau défini statiquement, ainsi que le rang n de la dernière valeur connue, on trouve au prix d'un encombrement mémoire, un algorithme linéaire.
Quant à calculer récursivement le n-ième terme de la suite de Fibonacci, effectivement c'est une drôle d'idée ;D
J'imagine que ça se présente de cette manière :
Ceci-dit, on peut le faire aussi avec une variable "auto" en dehors du scope des fonctions... Peut-être moins propre et moins rapide, vu que les "static" ne sont pas sur la pile.