Reprise du message précédent :

DarkLord a écrit a écrit :     nope j'ai mal au cheveu today. J'ai quitté le boulot un peu plus tot puis recherche d'appart donc

bon courage, j'ai connu ca y a pas longtemps !

Le revoila el_gringo
J'avais posté ça juste avant de quitter le bureau. Vous vous êtes déchainés sur mon topic. J'aime !
 

• L'intéret des méthodes const ds ce cas:

int MaMethode () const {...corps}
c à dire, l'intéret de déclarer une méthode constante, c'est énorme. Si t'as une instance qui est déclarée const, tu ne pourra y appliquer QUE les méthode const justement. Comme ça, il est garanti que la valeur de cette instance ne change pas.
Si ça ça n'existe pas en Java, je comprend pas comme ça marche quand une instance est final ! On peut y appliquer quoi comme méthode ? parce que si on peut y appliquer des setter par exemple, je comprend plus moi. A moins que... en java, final ça s'applique à la référence, pas à l'instance pointée par cette référence, c ça ? c à dire que la valeur de l'instance peut changer (on peut y appliquer des setter par exemple), mais l'instance pointée par un référence sera toujours la même. g bon !?
genre, voila ce que j'pense :

c ça ? Si c ça, en Java, il manque ce fameux "const" alors !
 

• L'intéret d'une valeur de retour constante, bah il est pas bien compliqué à comprendre. Du moment qu'on estime que ça n'aurait aucun sens de modifier une valeur de retour, on met une valeur de retour constante. C pas frcnahement essentiel, mais j'aime assez.

c'est ca ...
 
tu sais, Java il y a pas mal de trucs comme ca qui "manquent". Ils ont préféré la simplicité de programmation à la "puissance syntaxique" du langage.

 
Ouais, mais là, je trouve que c dommage qd même. c pas bien compliqué comme concept, et puis ça améliore la sérucité (niveau programmation j'veux dire!). Java est bien censé être porté sur la sécurité normalement. Moi j'aurais pensé que ce "const" c'était issu de la POO en général. J'vais écrire à Sun tient. J'vais leur dire de faire qqch pour le prochain JDK !

el_gringo a écrit a écrit : Le revoila el_gringo J'avais posté ça juste avant de quitter le bureau. Vous vous êtes déchainés sur mon topic. J'aime !

Nous aussi !

Bien expliqué sur ce coup ! J'avais pas pensé à ça. !
Et pour l'avoir vérifié, je confirme que ça marche comme ça.

Je veux bien te croire, c'est le jour où j'en aurai besoin que je me dirai : "Ha mais oui, c'est de ça qu'il parlé, c'est clair que ça sert ce truc !"
 
P.S. : Sacré topic

en fait, je voulas juste complèter, je suis ps sur d'avoir été clair sur un truc :
Dans une méthode constante (mot clé "const" après la définition des paramètres), c comme si tous les attribut membres de la classe étaient constants (mais ils sont utilisables en lecture quand même, constrairement à dans une méthode static).

el_gringo a écrit a écrit :     Ouais, mais là, je trouve que c dommage qd même. c pas bien compliqué comme concept, et puis ça améliore la sérucité (niveau programmation j'veux dire!). Java est bien censé être porté sur la sécurité normalement. Moi j'aurais pensé que ce "const" c'était issu de la POO en général. J'vais écrire à Sun tient. J'vais leur dire de faire qqch pour le prochain JDK !

 
discours commercial à la con ...

benou a écrit a écrit :     discours commercial à la con ...

 
Bah non... j'entend pas "sécurité" au sens que les pirates doivent avoir peur de Java. J'veux dire, sécurité au niveau du code. Avec Java, on est censé produire ^plus facilement du code sur, qui plante pas quoi à la moindre modif quoi.

c'était "robuste" le mot adéquat alors !  

bobuse a écrit a écrit : c'était "robuste" le mot adéquat alors !

 
Ouais, "robuste", "sûr", vous titillez les jeunes !

l'utilisation de final pour const  
ca n'est pas trop l'esprit je crois.
(pas la meme utilité, pas le même résultat)
 
De toute facon C++ est beaucoup plus riche au niveau
de ce que tu peux exprimer donc const s'avere necessaire dans certains cas. (appel d'une méthode sur une non-lvalue par exemple)
 
LeGreg

 
Bah dans certain cas, final (en java), et const (en C++), c équivalent, par exemple, dans la déclaration d'une méthode :

• en Java :

  Code : int MaMethode (final MaClasse parametre) {....}

• en C++  :

  Code : int MaMethode (const MaClasse& parametre) {....}

Bref, un final appliqué à une instance, c un const sure une référence d'objet.
Et un final sur une type primitif, c la même chose que const sur un type primitif.
 
Le 2e paragraphe de ton post, g pas compris ce que tu dis (non-lvalue, c quoi ça !?)

une non-lvalue c'est une entité que tu ne peux pas placer
a gauche d'un opérateur d'assignement ( operator = )
lvalue= 'left value'.
 
En java ca n'a pas de sens parce que c'est java
(tout est une lvalue sauf les final mais comme
quelqu'un le notait ce sont des "references finales", donc
on n'a pas ce probleme)
par contre en C++, ca arrive assez fréquemment
quand tu veux écrire des choses compactes  
de faire appel à des méthodes sur des temporaires.
Si ces méthodes sont non const ca ne marche pas.
de meme que faire appel à une méthode qui accepte en argument
une reference non const, lui passer une non-lvalue ne passera pas.
 
de plus l'ecriture correcte de l'operateur [] nécessite de faire
la distinction (par surcharge) entre la version const et non const. (en C++)
 
A+
LeGreg

pour arriver au resultat de la constness sur les objets java
une méthode connue c'est de proposer une interface "const"
sur un objet.
 
Exemple: tu as une classe Point avec un setX() et un setY()
ainsi qu'un getX() et un getY().
 
ce que tu vas faire c'est définir une interface ConstPoint
mais avec juste les méthodes getX() et getY()
 
Et une méthode qui acceptera un ConstPoint en argument ne pourra pas faire de modification de X et Y
(sauf en castant dynamiquement).
 
A+
LeGreg

 
ha, c pas con ça !
Merci du tuyeau. Excellente info. J'utiliserai...

 
Non ca n'a pas le meme resultat
le final sur une reference indique juste qu'on ne peut pas modifier la reference pendant le cours de la méthode par contre l'objet peut lui tres bien etre modifié.
(ca marche quand c'est un int mais l'interet est.. limité)
 
LeGreg

final c'est de l'optimisation.
(sauf pour l'utilisation type constante entiere..)
 
const c'est de la type safety
 
LeGreg

 
ha, merde...
autant pour moi, j'croyais que const sur un passage par référence faisait que c'était la référence qui était constante, pas l'instance vers laquelle elle pointe.

je remonte ce topic car j'ai besoin d'un complément d'explication
 
je ne sais plus l'avantage de taper final à une variable simple perdue dans un bout de code...
 
Exemple: j'ai chipoté avec mon IDE Java (IntelliJ pour l'histoire) et j'ai utilisé l'outil "Inspect code".
 
Il m'a sorti quelques variables dans mon code qui n'était pas modifiées (elles servaient de réceptacles à des requêtes un peu longues dans des objets) et m'a demandé si je voulais le taper en final.
 
à part respecter la logique qui veut qu'une variable qui ne sera pas modifiée soit déclarée constante:  
 
- qu'est-ce que ça change au point de vue de la JVM ?
- est-ce une optimisation à part entière ?
 

ha ben j'avais pas dit que des conneries a l'epoque

 
tous ces trucs là doivent être écrits dans des contrats clairs, qui permettent de spécifier bien plus de trucs que ce que permetent les mots-clefs du C++. Je suppose que voyant que la bataille des mots-clef était vaine, ils ont abandonné en attendant un truc plus solide.
 
Maintenant, on attend encore un truc standard pour les contrats de java, et plus tard un compilo capable d'en tirer parti. Le pb ça va être de faire avaler le langage de spécification de contraintes aux utilisateurs.