Discussion :

[oodini]

Hello,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
0
1
2
3

?

[Steph_ng8]

Hello !
Bah il suffit de tester, non ?

Plus sérieusement, c'est possible (et ça fonctionne ! ).
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...

[koala01]

Salut,

Oui, c'est tout à fait légal

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

[oodini]

Oui, c'est tout à fait légal

A la bonne heure. :-)

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.

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.

[3DArchi]

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)

[oodini]

(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 ?

[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.

[oodini]

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

[therwald]

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

[koala01]

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)

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

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

[Steph_ng8]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[ptyxs]

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

[Flob90]

@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).

[ptyxs]

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

[Steph_ng8]

@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...

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

[Flob90]

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.

[therwald]

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

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

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

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

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.

[therwald]

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?

[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.

[koala01]

@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