Variable statique locale à une fonction membre

Hello,

Je me demandais si on pouvait utiliser dans une fonction membre des variables locales statique, comme dans :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class A { void maFonction(); };   A::maFonction() { static int pouet = 0; std::cout << pouet++ << std::endl; }   int main() { A monA;   monA.maFonction(); monA.maFonction(); monA.maFonction(); monA.maFonction(); }

---

et si oui, aurai-je bien comme résultat :

Code:

---

1 2 3 4

0 1 2 3

---

?

Hello !
Bah il suffit de tester, non ? :roll:

Plus sérieusement, c'est possible (et ça fonctionne ! :ccool:).
Par contre, de mémoire, la variable sera partagée entre toutes les instances.
Ce qui paraît logique, vu qu'une variable statique n'est initialisée que lors de sa première utilisation...

Salut,

Oui, c'est tout à fait légal

Citation:

---

Envoyé par Steph_ng8

Par contre, de mémoire, la variable sera partagée entre toutes les instances.
Ce qui paraît logique, vu qu'une variable statique n'est initialisée que lors de sa première utilisation...

---

En fait, la variable sera partagée entre tous les appels de la fonctions, quelle que soit l'instance au départ de laquelle la fonction sera appelée...

Cela peut s'avérer utile si l'on est sur que la variable doit toujours utiliser la meme valeur et qu'il s'avère couteux (en temps ou en ressources) de devoir la recréer ou la réinitialiser à chaque appel de la fonction.

Par contre, même cachée au milieu d'une fonction membre d'une classe se trouvant peut etre dans un espace de noms, il faut garder en mémoire que l'utilisation de variables statiques reste toujours problématique du fait du linkage dont elles font l'objet.

S'il n'y a rien qui interdit la manoeuvre, il s'agit quand meme d'avoir des raisons valables de travailler de la sorte :D

Citation:

---

Envoyé par koala01

Oui, c'est tout à fait légal

---

A la bonne heure. :-)

Citation:

---

Envoyé par koala01

Cela peut s'avérer utile si l'on est sur que la variable doit toujours utiliser la meme valeur et qu'il s'avère couteux (en temps ou en ressources) de devoir la recréer ou la réinitialiser à chaque appel de la fonction.

---

C'est le cas.

Citation:

---

Envoyé par koala01

Par contre, même cachée au milieu d'une fonction membre d'une classe se trouvant peut etre dans un espace de noms, il faut garder en mémoire que l'utilisation de variables statiques reste toujours problématique du fait du linkage dont elles font l'objet.

---

Je n'ai jamais été au clair, sur ces problèmes induits par les variables statiques.
A chaque fois, je résous au cas par cas, mais je n'en ai pas encore tiré de règle générale.

Citation:

---

Envoyé par oodini

Je n'ai jamais été au clair, sur ces problèmes induits par les variables statiques.
A chaque fois, je résous au cas par cas, mais je n'en ai pas encore tiré de règle générale.

---

A éviter.


(problème multithread, réentrance, fonction impure... Même 'locale' une variable statique souffre des mêmes tares qu'une variable globale)

Citation:

---

Envoyé par 3DArchi

(problème multithread, réentrance, fonction impure... Même 'locale' une variable statique souffre des mêmes tares qu'une variable globale)

---

Effectivement, je sais que dans le cadre d'une utilisation en multithread, il faut les éviter comme la peste (ou du moins, en toute conscience).

Je pensais plutôt aux problèmes d'édition de liens.

PS : Qu'est qu'une fonction impure ? Je suppose que ça n'a rien à voir avec les virtuelles pures ?

Une fonction est pure si son retour dépend uniquement des paramètres d'appel. Ça exclut des fonctions qui traitent une variable globale ou une statique locale, puisqu'elle ne fait pas partie des paramètres d'appel, influe sur le résultat, et introduit une mémoire des appels précédents.

Quelle est la différence avec une fonction réentrante, en ce cas ?

La réentrance est sur un autre niveau: c'est le fait de pouvoir traiter sans interférence correctement (c-à-dire avec un résultat conforme à son contrat) plusieurs appels simultanés à la fonction. Une fonction pure est ré-entrante, puisque par définition elle doit être dépourvue d'effets de bord susceptibles de changer le résultat pour un même jeu de paramètre, mais toute fonction ré-entrante n'est pas forcément pure (ex: une fonction dont l'appel change un état persistant du système).

EDIT: barré remplacé par vert: cette formulation me semble plus précise et donc plus juste

Citation:

---

Envoyé par therwald

Une fonction est pure si son retour dépend uniquement des paramètres d'appel. Ça exclut des fonctions qui traitent une variable globale ou une statique locale, puisqu'elle ne fait pas partie des paramètres d'appel, influe sur le résultat, et introduit une mémoire des appels précédents.

---

Tiens, à ce sujet, j'ai une question, exactement dans le fil du sujet...

What about les variables statiques constantes (quelle que soit leur position) :question:

La fonction qui l'utilise peut être ré-entrante, étant donné que, pour un même jeu de paramètres, nous obtiendrons une résultat identique.

Mais peut on la considérer comme pure malgré tout, ou, étant donné que le résultat dépend "d'autre chose que des paramètres" ou des membres de la classe (s'il s'agit d'une fonction membre), faut il la considérer comme impure :question:

Par exemple : si je définis PI comme étant 3.1415926, c'est une constante qui pourra etre utilisée... partout où l'on l'on travaille avec des courbes...

Je la définirai sans doute comme constante statique quelque part, et toutes les fonctions qui en auront besoin sauront où aller récupérer la valeur...

Mais est-ce que cela en fait des fonctions impures pour la cause:question:

Si j'ai bien compris, cette fonction est impure ?

Code:

---

1 2 3 4

void foo() { std::cout << "Hello World!" << std::endl; }

---

Petite parenthèse : d'où vient cette notion de fonction 'pure' (que je n'avais jamais rencontrée jusqu'ici dans aucun ouvrage) ?

@ptyxs: Je ne sais pas exactement d'où vient cette notion mais elle est très "utilisée" en programmation fonctionnel, tu trouveras souvent ce terme dans les articles d'introduction à la programmation fonctionnel destiné aux développeurs venant des autres paradigme (c'est ce qui fait que le mode de pensé est totalement différent).

@Steph_ng8: Oui elle l'est, et tu touches là un des point difficile de la programmation fonctionnel : comment gérer les IO (entre autre). Une solution : les monades (et tout ce qui en découle).

@koala01: Je pense que ca va dépendre, comme le C++ propose le mots-clé mutable, ce n'est pas trivial. Et il y a aussi les exceptions qui rentrent en jeux (si elle peut lancer elle est nécessairement impure), elles ne gènent pas nécessairement pour la réentrance par contre (le contrat peut resté respecté, AMA).

Eh oui, ça m'évoquait mes souvenirs de Lisp...
Sur la notion il y a une page fort claire de Wikipédia en anglais :
http://en.wikipedia.org/wiki/Pure_function

Citation:

---

Envoyé par Flob90

@Steph_ng8: Oui elle l'est, et tu touches là un des point difficile de la programmation fonctionnel : comment gérer les IO (entre autre). Une solution : les monades (et tout ce qui en découle).

---

Je viens de jeter un coup d'œil à la page Wikipédia, je n'ai pas vraiment compris... :P

Et effectivement, la notion de « fonction pure » me rappelle vaguement l'apprentissage de Caml...

La page wiki sur les monades ? C'est surtout une description "mathématique" de la chose. De plus ce qui est utilisé pour gérer les IO ce sont des fonctions monadiques, Bartosz Milewski l'explique sur son blog (avec Haskell et il "compare" avec le C++ certains points des deux langages).

Pour CAML j'ai un doute, je me demande si il n'est pas fonctionnel "impure", dans ce cas la notion de fonction pure est bien "utilisé" mais les problèmes apportés par les IO par exemple sont contournés en utilisant des fonctions impures.

Citation:

---

Envoyé par koala01

Tiens, à ce sujet, j'ai une question, exactement dans le fil du sujet...

What about les variables statiques constantes (quelle que soit leur position) :question:

La fonction qui l'utilise peut être ré-entrante, étant donné que, pour un même jeu de paramètres, nous obtiendrons une résultat identique.

Mais peut on la considérer comme pure malgré tout, ou, étant donné que le résultat dépend "d'autre chose que des paramètres" ou des membres de la classe (s'il s'agit d'une fonction membre), faut il la considérer comme impure :question:

Par exemple : si je définis PI comme étant 3.1415926, c'est une constante qui pourra etre utilisée... partout où l'on l'on travaille avec des courbes...

Je la définirai sans doute comme constante statique quelque part, et toutes les fonctions qui en auront besoin sauront où aller récupérer la valeur...

Mais est-ce que cela en fait des fonctions impures pour la cause:question:

---

Eh...si on parle d'une vraie constante, sans utiliser de particularité technique pour modifier sa valeur en cours de route...je pense que du coup, ce n'est pas une variable au sens mathématique. Je pense que du coup on peut adopter une définition de "résultat constant à paramètres constant" réduite, disons à une exécution donnée, ou du moins excluant les changements des valeurs dues à la recompilation. Du coup, les fonctions en question doivent pouvoir être considérées comme pures. Si on recompile après avoir changé une constante, ce n'est plus vraiement la même fonction.

Citation:

---

Envoyé par Flob90

Et il y a aussi les exceptions qui rentrent en jeux (si elle peut lancer elle est nécessairement impure).

---

Pourquoi cela rendrait-il la fonction impure? Une exception, après-tout, est un résultat...si l'exception est reproductible, cela revient à un domaine de définition qui exclut certaines valeurs de l'ensemble de départ (des paramètres, quoi), mais pourquoi cela empêcherait-il une fonction d'être pure?

@therwald: AMA, une bonne utilisation des exceptions revient à lancer une exception dans une fonction dès que le contrat de celle-ci est brisé, je te laisse arrivé à la conclusion à laquelle je pensais.

@koala01: En relisant ton interrogation je me suis demandé si la définition de la "pureté" concernait des résultats dont les sémantiques sont équivalentes ou des résultats "strictement" équivalent (si la fonction est appelé avec les même variables).

Dans le premier cas alors l'utilisation de mutable n'est plus un problème (une donnée membre mutable qui influe sur la sémantique n'est, AMA, pas une bonne idée). Il ne resterait donc que les exceptions.

Citation:

---

Envoyé par Flob90

@therwald: AMA, une bonne utilisation des exceptions revient à lancer une exception dans une fonction dès que le contrat de celle-ci est brisé, je te laisse arrivé à la conclusion à laquelle je pensais.

@koala01: En relisant ton interrogation je me suis demandé si la définition de la "pureté" concernait des résultats dont les sémantiques sont équivalentes ou des résultats "strictement" équivalent (si la fonction est appelé avec les même variables).

Dans le premier cas alors l'utilisation de mutable n'est plus un problème (une donnée membre mutable qui influe sur la sémantique n'est, AMA, pas une bonne idée). Il ne resterait donc que les exceptions.

---

Nous pourrions donc dire que l'exception qui va confirmer la règle qu'une fonction manipulant une globale ou une statique sera impure est justement le cas où cette globale ou cette statique est constante : d'un appel à l'autre (utilisant le meme jeu de valeur), le résultat n'est absolument pas modifié ni modifiable ;)

Salut,
La constance porte sur l'utilisation de la variable pas sur sa valeur effective :

Code:

---

1 2 3 4 5

static volatile const TYPE &io_mem_map; void fonction_impure() { io_mem_map; // peut avoir un effet de bord indépendant des paramètres et ce même si l'instruction n'a l'air d'être qu'une lecture sans rien d'autre }

---

@flob : 2 intérêts des fonctions pures : elles ne peuvent être évalués qu'une seule fois puis leur résultat 'caché' (transparance référentielle). L'autre avantage est la possibilité de réordonner différents appels indépendants (ça permet donc des optimisations)

Citation:

---

Envoyé par 3DArchi

Salut,
La constance porte sur l'utilisation de la variable pas sur sa valeur effective :

Code:

---

1 2 3 4 5

static volatile const TYPE &io_mem_map; void fonction_impure() { io_mem_map; // peut avoir un effet de bord indépendant des paramètres et ce même si l'instruction n'a l'air d'être qu'une lecture sans rien d'autre }

---

---

Un cas de "naïveté technique" de ma part: je ne parlais pas de référence constante à un objet pouvant être modifié par ailleurs (comme les références à des registres matériels ou autre réf constante à des valeurs pouvant varier par le biais d'évènements matériels ou d'autres références non constantes...). Par contre, le premier exemple évoqué (la valeur de PI) est bien une constante au sens mathématique et non syntaxique du terme...et là ça n'empêche pas une fonction d'être pure, comme le disait koala01: le résultat est toujours le même pour les mêmes paramètres.

@Flob90: je ne suis pas entièrement d'accord avec toi: pour moi, fonction pure <=> le résultat est toujours le même pour les mêmes paramètres. Or si l'exception est lancée pour signaler que les valeurs de paramètres utilisées sortent du domaine de définition (un usage à mon sens normal), alors chaque fois qu'on appellera la fonction avec ces paramètres on obteindra l'exception en retour. Pour moi ça n'empêche donc pas la fonction d'être pure. (je ne parle pas d'autres cas où l'exception survient pour d'autres raisons, qui généralement impliquent des ressources extérieures indisponibles et autres états incorrects qui empêchent de toutes façons la fonction d'être pure...)

@therwald: Oui je suis totalement d'accord avec ta définition de la pureté, sauf que comme je le disais, je pense que les exceptions ne doivent être utilisées qu'en cas de rupture du contrat de la fonction (*), de là on en déduit qu'elle n'est pas réentrante, ce qui implique impure.

(*) Dit autrement je ne considère pas le cas que tu cites comme une utilisation légitime des exceptions, j'utiliserais plutôt une assertion si vraiment je tiens à pister les erreurs de programmation.

@3DArchi: J'avais pas posé la question ni dit le contraire, mais je suis d'accord et c'est une précision qui peut être utile :ccool:

Citation:

---

Envoyé par Flob90

rupture du contrat de la fonction

---

Je ne suis pas certain de comprendre ce que tu entends par là, pourrais-tu préciser pour ma gouverne?
EDIT: ma question n'est peut-être pas claire, donc je précise: pour moi, rupture du contrat de la fonction <=> bug
A la base une fonction bien foutue respecte son contrat (et le contrat inclut parfois la description de cas (exceptionnels) où il n'est pas possible de répondre à la demande exprimée par l'appel ==> exception.)

Disons que j'ai une fonction qui créé un objet d'un certain type à partir d'un index conpris entre 1 et 10 et donne la responsabilité de la durée de vie à l'appelant.

Le contrat pourra être :
Entrée : un entier entre [1 et 10) (c'est la partie du contrat que doit respecter l'utilisateur)
Sortie : Un pointeur sur l'objet créé.

Une implémentation (T un type avec un constructeur prenant comme paramètre un type entier) :

Code:

---

1 2	T* function(char c) { return new T(c); }

---

La programmation par contrat (*) me dit que si je respect le contrat d'entrée alors la fonction doit respecter le contrat de sortie, or si new ne peut allouer la mémoire nécessaire la fonction ne peut respecter son contrat (elle peut pas retourner un pointeur sur l'objet) : rupture du contrat. Par contre si je ne respecte pas le contrat d'entrée (je donne 0 comme entrée par exemple), la fonction n'a rien a respecter et peut avoir un comportement quelconque.

AMA, le premier cas est un cas d'utilisation d'exception, alors que le second non (**). C'est d'ailleurs la politique utilisée par la bibliothèque standard si tu prètes attention au cas où sont lancées les exceptions (sauf quelques cas à part).

Note au passage que ca apporte certains avantages : pas besoin de tester la non-nullité du pointeur retourné puisque le contrat m'assure que c'est un pointeur sur un objet. C'est d'ailleurs ce que tu fais quand tu utilises new (version classique) tu utilises ce qu'il te donne sans vérifier au préalable qu'il est non nul.

(*) C'est juste une explication grossière, il y a peut-être des détails que je ne connais pas.

(**) Une raison pourrait être que si tu fais une erreur sur les paramètres passés à l'appel tu ne peux pas réelement rétablir un fonctionnement correct : tu sais pourquoi la fonction ne peut se faire mais pas pourquoi les paramètres sont mauvais, comment les corriger ?

Imagines une telle fonction, mets la dans un bloc try, mets des paramètres d'appel incorrect, que mets-tu dans le bloc catch correspondant pour récupérer un comportement correct ? A part stopper le programme tu ne peux rien faire : l'erreur se répétera tant que tu n'auras pas corrigé l'erreur dans le code pour qu'un tel appel ne puisse arriver : c'est une erreur de programmation (ie c'est le développeur qui s'est planté).

OK
Merci pour ces explications, je me coucherai moins bête ce soir ;)

Pour ce qui est des paramètres d'appel, concernant les paramètres incorrects pour cause de programmation incorrecte, je suis d'accord avec toi.
Par contre je pense que l'équivalence valeurs hors domaine = erreur de programmation a des exceptions.
Par exemple: les paramètres d'appel viennent d'une source de données quelconque. Les valeurs en question proviennent d'un processus différent de celui qui traite. Nous considérons que dans le cas normal les données seront correctes.
Exemple de traitement d'exception: envoi d'un message d'exploitation signalant la présence de données incorrectes, à corriger, puis passage à la suite des données.
Sur ce cas, il me semble normal d'utiliser un lancement d'exception.

Citation:

---

Envoyé par therwald

Par contre je pense que l'équivalence valeurs hors domaine = erreur de programmation a des exceptions.

---

Humour involontaire :)

Citation:

---

Envoyé par Flob90

AMA, le premier cas est un cas d'utilisation d'exception, alors que le second non (**).

---

std::invalid_argument ne sert pas dans ce genre de cas ?

Citation:

---

Envoyé par Flob90

C'est d'ailleurs ce que tu fais quand tu utilises new (version classique) tu utilises ce qu'il te donne sans vérifier au préalable qu'il est non nul.

---

L'opérateur new ne lance pas un std::bad_alloc lorsqu'il ne peut pas allouer la mémoire ?

@Steph_ng8: Oui, mais elle est loin d'être très utilisée (*) ("sauf quelques cas à part"). Pour new (version classique), oui il lance, mon message ne dit pas le contraire.

@therwald: Si ta source de donnée peut te donner des paramètre invalides, alors je pense que c'est plutôt dans ton programme que tu dois vérifier la validité avant d'appeler la fonction (entre la récupération des données et l'appel), et pas directement dans celle-ci.

(*) Ma suggestion de regarder la bibliothèque standard s'appliquait plus spécifiquement à l'ensemble itérateurs/conteneurs/algorithmes.

Une autre raison d'utiliser des traitements par exceptions dans le cas d'erreurs de validité des paramètres est que parfois on ne peut assurer facilement la détection...l'erreur peut être du genre plus subtile qu'un null ou un 11 pour une plage 0..10, du coup l'assert ne suffit pas car alors on veut du diagnostic et report même en prod

Citation:

---

Envoyé par Flob90

@therwald: Si ta source de donnée peut te donner des paramètre invalides, alors je pense que c'est plutôt dans ton programme que tu dois vérifier la validité avant d'appeler la fonction (entre la récupération des données et l'appel), et pas directement dans celle-ci.

---

Je pense que ça se discute car en fonction de la complexité de l'appli cela peut mener à un clutter de la couche appelante...pour moi, quelque part, c'est à la fonction de savoir quel est son domaine de définition.

Salut,
Le contrat engage un code vis à vis d'un autre. Donc tout ce qui vient de l'extérieur - donnée dans une base, saisie utilisateur, message réseau, registre µ, etc... - doit être vérifié avant d'être propagé dans le code.


Programmation par contrat, application en C++ par Julien Blanc

@3DArchi merci, en lisant quelques lignes du document j'ai compris le concept et la raison derrière.
@Flob90 du coup je comprends ton point de vue.
Ca ne s'applique pas à mon environnement professionnel, où faire confiance à l'appelant est trop risqué (je suis donc plutôt dans un contexte de programmation défensive).

Citation:

---

Envoyé par therwald

Ca ne s'applique pas à mon environnement professionnel, où faire confiance à l'appelant est trop risqué (je suis donc plutôt dans un contexte de programmation défensive).

---

La conséquence est un code 'enflé' et du masquage de bug. Mais, je comprends cette barrière 'culturelle' souvent dans le monde embarqué qui fait s'accrocher à une programmation défensive.

je trouve l'exemple de flob mal choisi; appeler new rend deja la fonction impure, et c'est le comprtement de new qui est deja impur dans ta méthode.
par exemple, une fonction pure devrait en permanence retourner le même pointeur si tu l'appelles avec les mêmes paramètres, ce que new ne fait pas.

pour un exemple plus simple, prenons la méthode "acos"; acos a une valeur d'entrée qui doit être comprise entre -1 et 1, au dela le résultat est (un nombre complexe mais en général on s'en fout) indéfini.

la méthode:

Code:

---

1 2 3 4 5 6 7

float acos(float x) { if(x < -1 || x > 1) throw MathError(x); else return (developpement de taylor de x); }

---

cette fonction peut être considérée comme pure; si tu appelles acos(-2) elle fera toujours la même chose, a l'infini. si tu appelles acos(0.1) aussi. pas comme new(int) ou etc etc.



cependant même si d'un certain point de vue cette méthode est pure, la pureté dans certains langages est utilisée pour mettre un résultat en cache et ne pas rappeler la fonction; par exemple, les vieux jeux vidéo avaient une table de cos(x) pour x entre 1 et 180 pour ne pas recalculer cos(x). Or, c'est possible seulement parce que cos(x) est pure. Si une exception est levée par une méthode, même si c'est systématique, il va etre difficile d'utiliser une fonction pure comme une fonction pure; en effet, si acos(x) renvoie une exception, elle ne renvoie pas le résultat; il faudrait donc un systéme de cache qui est capable de traiter les cas exceptionnels aussi.

Code:

---

float sqrcos = cos(x)*cos(x);

---

ce code pourra etre optimisé puisque cos est pure;

Code:

---

float sqracos = acos(x)*acos(x);

---

celui la possiblement aussi puisque l'exception n'est pas traitée;
au dela de ces exemples simples cela commencera a ressembler a un casse tête pour le compilateur. Autant dire que même si dans la logique c'est pur, dans les faits ca ne sera sans doute pas une fonction pure.

@screetch: Mon exemple n'avait rien à voir avec la pureté mais avec la programmation par contrat (*). Pour ton exemple, j'essaie justement d'argumenter dans ce message que c'est une utilisation assez critiquable des exceptions (donc j'allais pas en faire un exempl :aie:). Pour résumer le raisonnement que j'ai fait (qu'il soit juste ou non :ccool:) : exception => rupture de contrat => non réentrante => impure. Ton exemple n'entre pas dans la première implication, issue de la programmation par contrat, d'où la conclusion à laquelle tu arrives (fonction pure lancante).

Citation:

---

Envoyé par Flob90

@Steph_ng8: (...) Pour new (version classique), oui il lance, mon message ne dit pas le contraire.

---

Désolé, j'avais lu trop vite.
En relisant le message, j'ai compris où tu voulais en venir.