Discussion :

[TabrisLeFol]

Bonjour,
Je voudrais savoir si il existe un langage permettant cela.

Des constantes de types primitives sont disponibles dans de nombreux langages mais en ce qui concerne les objets, je ne connais rien d'équivalent.
Le problème est : ayant défini une classe produisant des objets pouvant être modifiés, est-il possible d'instancier cette meme classe afin de produire un objet que l'on sait inchangeable ?
(En java, le mot clef final ne permet de garantir seulement que ce soit toujours le même objet (plus exactement, la même adresse) qui soit stocké par la meme variable, rien ne garantit donc que les paramètres de cet objet ne changent.

De meme existe-t-il un langage permetttant de spécifier que le résultat d'une fonction est purement lié à ses paramètres ? Autrement dit, cette fonction ne devrait rien changer sur d'autres données dans le programme et retourner un résultat en fonction des paramètres.
Un exemple est min(5,8) que l'on sait constant.

Dernier point, déclarer une fonction comme ne changeant pas les attributs d'un objet (exemple, un accesseur). C'est-à-dire à la fois ne permettant pas de changer la valeur explicitement mais aussi l'appel de fonction pouvant en théorie les modifier.

Voilà, si vous avez des commentaires, des idées, des pistes, vous êtes les bienvenus.
D'avance merci

PS : Bien sur, tout cela peut se coder mais cela risque de produire un résultat lent (dû à la gestion des exceptions) mais il est difficile (voire impossible) d'imposer cette règle et on rique aussi de produire de nombreux bugs...

[Luc Hermitte]

C'est un troll ?
Le C++ répond de sûr à ces besoins à l'aide du mot clé const. Il permet de spécifier qu'une donnée est immuable (simple variable sur la pile, pointée, ou même un paramètre formel), ou qu'une fonction membre ne modifiera pas l'état (officiel) de l'objet sur lequel elle s'applique.

(Officiel, car on peut accepter qu'un attribut soit modifié sans que pour autant on ne considère que l'état de l'objet soit modifié ; pratique pour des classes proxy-cache qui vont charger une lourde donnée qu'au (premier) rare moment où elle est requise.)

J'ai oublié ce que permettaient les autres grands langages comme Ada ou Eiffel.

[Jedai]

Si tu veux tu as aussi les langages fonctionnels comme Ocaml ou Haskell où les propriétés que tu cites sont valables par défaut (les "variables" sont constantes, une fonction n'a pas d'effet de bord et est une vraie fonction du point de vue mathématique). Pour invalider ces propriétés dans ces langages, il faut faire appel à des constructions particulières du langages.

--
Jedaï

[TabrisLeFol]

@ jedai : ok, merci je vais regarder du coté de ses deux langages.

C'est un troll ?

@ Luc Hermitte : Ce fut une bonne blague.
Justement le C++ ne convient pas. Tu admets toi meme qu'un "objet constant" peut avoir ses atributs changés et en ce qui concerne les fonctions membres, si mes souvenirs sont exacts, on ne peut en effet pas changer la variable directement mais l'appel d'une fonction tierce le permettant n'est pas refusé... Mon problème est bien que l'aspect "officiel", n'est qu'un aspect.

[Hephaistos007]

Ce que tu demandes relève du génie logiciel, et si il y bien un langage que les adeptes du GL aiment par dessus tout c'est ADA.

A ce propos, en consultant une FAQ ADA je tombe sur ceci :

Que signifie le pragma Pure?

Cette directive de compilation signifie que le paquetage auquel elle
s'applique ne contient que des sous-programmes sans effet de bord, et
déterministes. En gros, les sorties ne dépendent que des entrées, et
pas d'un quelconque état interne ou externe.

[TabrisLeFol]

J'ai également entendu parlé de ADA, entre autre par mon prof d'algo qui a dit que je sais plus critiquait ADA... Mais bon je ne me rappelle ni de l'auteur de la critique ni de la nature de celle ci...
Je crois que c'était sur le fait que dans le cas de tests multiples on ne pouvait pas savoir l'ordre d'execution.... Enfin bon, je vais me renseigner et voir tout cela.

OCaml m'interesse d'autant plus que les etudiants venant de prepas ont de fortes chances de l'avoir pratiqué.
Quelqu'un connaitrait des sources me permettant de comprendre les differences entre les langages cités sur ce thread? Ou pourrait me donner des raisons particulières pour utiliser un en particulier.
D'apres ce que j'ai compris OCaml offre beaucoup de possibilitées.
ADA "vient" de se mettre à l'objet.

[Luc Hermitte]

@ Luc Hermitte : Ce fut une bonne blague.
Justement le C++ ne convient pas. Tu admets toi meme qu'un "objet constant" peut avoir ses atributs changés et en ce qui concerne les fonctions membres, si mes souvenirs sont exacts, on ne peut en effet pas changer la variable directement mais l'appel d'une fonction tierce le permettant n'est pas refusé... Mon problème est bien que l'aspect "officiel", n'est qu'un aspect.

Non. Je n'ai pas développé et expliqué ce qu'est la mutabilité en C++. Ce peut être fait si le design le requiert. Par défaut il est impossible de modifier la valeur d'un attribut depuis une fonction membre const. Ce peut être contourné dans des cas particuliers bien précis et tout à fait justifiés (si si!!), mais cela demande de savoir des petites choses supplémentaires qui ne sont pas le défaut.

De plus, quand tu as un objet qui est non modifiable dans la portée courante, tu ne pourras appeler dessus uniquement:
- des fonctions membres const
- des fonctions qui le prendront en paramètre et certifiront ne pas pouvoir le modifier (soit par copie quand il y a une sémantique de valeur (et que le constructeur de recopie travaille à partir d'une référence constante), soit par référence constante, soit par pointeur vers donnée constante)

Et en plus c'est transitif. Dans le contexte de ces fonctions qui déclarent ne pas modifier l'objet, l'objet est non modifiable et donc on ne peut appeler que ...
Bref, on ne peut pas passer via une fonction tierce.


Quant à l'"officiel", c'est un aspect très important. Par exemple, prenons un contrat qui permet de demander l'état d'un objet. Typiquement, la demande d'état ne modifie pas l'objet observé (oublions Schrodinger un moment).

Code :

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

1
2
3
4
5
struct ContractState {
    State_t state() const { return fetchState(); }
private:
    virtual State_t fetchState() const = 0;
};

L'implémentation par défaut pour des objets locaux ne va effectivement pas modifier quoique ce soit. En revanche, pour un objet qui agit comme un proxy vers un état distant, il y a bien quelque chose qui peut changer : le fait que le servant soit tombé. Alors là, autant mettre à jour la référence à cet objet distant.

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
struct ProxyState : ContractState {
    ....
private:
    State_t fetchState() const {
        try {
            if (!CORBA::is_nil(m_remote))
                return m_remote->getState();
        } catch (...) {
            m_remote = IStubState::_nil();
            HandleException("fetchState");
        }
        return State_t::failed;
    }

    mutable IStubState_var m_remote;
};

Les proxys sont des cas classiques où on viole la const-correctness. Ce n'est pas lié au langage, mais au design.


Il y a toutes fois un effet de bord au const en C++. Le const des fonctions membre concerne les valeurs des attributs, et non les valeurs pointées par les attributs.
En rajoutant des sur-couches, il y a moyen de toujours plus blinder. Je pense (réflexion superficielle de moins de 5 minutes) à déporter les attributs (non mutables) vers des objets les encapsulant et offrant deux accesseurs. Un const vers un "ptr const*", et un non const vers un "ptr*". Résultat, les fonction membre const devront passer par l'accesseur const de l'enveloppe. Ce qui assure la non modification. AMHA, un peu compliqué pour pas grand chose. Hum... D'un coup j'ai un doute. Ne serait-ce pas ce que font les pointeurs intelligents de boost ..?


Ada (avec des minuscules, en référence à Ada Loveless) s'est mis à l'objet il y a un paquet d'années maintenant.

[TabrisLeFol]

De plus, quand tu as un objet qui est non modifiable dans la portée courante, tu ne pourras appeler dessus uniquement:
- des fonctions membres const
- des fonctions qui le prendront en paramètre et certifiront ne pas pouvoir le modifier (soit par copie quand il y a une sémantique de valeur (et que le constructeur de recopie travaille à partir d'une référence constante), soit par référence constante, soit par pointeur vers donnée constante)

Et en plus c'est transitif. Dans le contexte de ces fonctions qui déclarent ne pas modifier l'objet, l'objet est non modifiable et donc on ne peut appeler que ...
Bref, on ne peut pas passer via une fonction tierce.

Je ne savai pas cela. Ainsi le paramètre implicite, this, est "déclaré" const si la fonction est const si j'ai bien compris. J'avais retenu que le const permettait seulement d'empecher que l'on modifie directement les attributs mais que cela n'empéché pas d'appeler des fonction tierces. Par contre je me pose actuellement une nouvelle question, le const est lié à la varible et non l'objet, non? Serait possible alors de passer l'objet const dans une variable "non const" que cela soit directement ou par l'intermediaire d'une fonction?

Edit : faut que je trouve un article complet sur le const C++, je vais chercher.

[Jean-Marc.Bourguet]

ADA "vient" de se mettre à l'objet.

Ada a ete le premier langage objet avec une norme internationnale. En 1995. (Common Lisp et Simula ont eu des normes nationales avant).

[Jean-Marc.Bourguet]

Par contre je me pose actuellement une nouvelle question, le const est lié à la varible et non l'objet, non? Serait possible alors de passer l'objet const dans une variable "non const" que cela soit directement ou par l'intermediaire d'une fonction?

Le seul moyen d'enlever const est de passer directement ou indirectement par des cast
(soit a la C, soit const_cast).

A+

[Luc Hermitte]

Dans le cadre d'une fonction membre const, c'est "*this", l'objet pointé, qui est const. "this", le pointeur, est toujours const.

Et const est très intrusif. Limite viral quand il s'agit de rendre const-correcte une petite fonction apparement innocente au milieu d'un code non const-correct.

Le const ne se contourne pas en passant via d'autres fonctions. Seules les convertions, comme avec const_cast<>, peuvent permettre de passer outre.
Quant à copier l'objet const dans un autre ... ce n'est possible que pour les objets qui sont copiables, et ce que tu pourras modifier sera le nouvel objet. Pas l'ancien. Pour la copie de pointeurs, le nouveau devra obligatoirement être déclaré comme un pointeur vers une donnée const.
Des références ? N'importe quel cours, non ? Des articles sur GOTW aussi peut-être ?

[TabrisLeFol]

ok, je pensais que les systemes mis en place dans le C++ était moins "performant. J'ai appris quelquechose.
En ce qui concerne les cours, je ne dis pas tous mais certains passent assez vite le const.