à l'instruction "tmp.copy (this);" ca passe ou ca casse selon vous ?
je précise bien que l'instruction "tmp = new LiOPermutation ();" est en commentaire.

Non.
tmp vaut null à ce moment donc un joli NullPointerException t'attend derrière le buisson
 

ta gueule sale noobs, va lire le manuel en cherchatn google.
 
 
 
(scusez, des fois ça fait du bien)
 
Sinon, pour paraphraser au-dessus, les variables de type référence sont initialisées par défaut à null. Appeller une mathode sur null conduit à une NullBiduleException, appellée aussi NPE.

Ha jsuis content vous me rassurez . Bon, quand je lance tout ça au debugger, le contenu de la variable tmp est :
tmp = [0, 0, 0, 0] (le tableau mChain est de taille 4). Le pointeur tmp n'est donc pas nul ! et donc l'instruction passe très bien.
Pourquoi ?   ... je l'ignore completement. Au debuggeur sans faire un stepin dans cette methode improve (et toujours sans l'instruction new), tout se déroule bien. Donc pourquoi tmp = [0, 0, 0, 0] et non null ?  

Après avoir commenté cette fameuse ligne, le source a bien été recompilé ??

 
  tout a fait, d'ailleur je viens juste de démarrer javabeans la, et tout marche bien. (toujours sans l'instruction new).
Conclusion : ca sert a rien l'instruction "tmp = new ..."
 
Apparemment, oublié l'instruction new, ce n'est pas un plantage systematique. Un peu comme faire deux instruction delete successive en C++ sur le meme objet. Par contre a terme ca peut planter.

non, giz, tu t'es planté quelquepart.

 
Ta méthode copy(), elle est pas déclarée 'static' par hasard ???

 
non.
J'avais donc corrigé en mettant le new. Et maintenant je ne peux plus revenir comme avt. (sans le new) ca compile plus, ca me dit "lio/individuals/permutations/LiOPermutation.java [151:1] variable tmp might not have been initialized "
 
Ca devait etre le fichier .class qui merdait (ca recompilait pas vraiment).

 
Ca m'arrive quelques fois sous Eclipse

Tiens une autre question de noob qui me passe par la tête :
 
voici l'instruction suivante :

 
précision :
 
upperBound et lowerBound sont 2 int de valeurs quelconques avec upperBound > lowerBound.
 
 
questions :
 
-En gros, comment le compilateur calcule la valeur (upperBound - lowerBound) et où la stocke-t-elle temporairement pour la comparer à Integer.MAX_VALUE ?    
-Ce test marche-t-il ? Si oui, comment ça se passe tout ça en mémoire ?    
 
- mêmes questions mais avec le test :

 
upperBound et lowerBound sont 2 doubles de valeurs quelconques avec upperBound > lowerBound.
 
Merci  

ça vaut toujours true, à partir du moment où un entier est toujours compris entre MIN_VALUE et MAX_VALUE

tu voulais dire false

 
C'est vrai que je me posais une question sans penser a la logique du test qui voulait dire "cet entier est-il sup au plus gros des entiers" forcément c'est faux. Du coup faudrait caster le "upperBound - lowerBound" en double pour faire la comparaison  

 
exact

Encore une question de noob. (on devrait en faire un topik unique : [topik unik] Question de noobs )
 
Quand on a une classe de base abstraite, y-a-t-il moyen d'y définir un constructeur abstrait de façon à ce que toutes les classes dérivées aient ce contructeur avec CE prototype implémenté. Je pense notamment au constructeur par copie qui garantie bien que l'utilisateur travaillera sur une copie et pas sur une reférence sur l'objet original.
 
Merci  

non, les constructeurs ne sont pas hérités, mais oui, on peut appeller les constructeurs de la super-classe depuis les constructeurs des sous-classes et oui, on peut mettre des constructeurs dans une classe abstraite :

sauf le constructeur sans argument, pour peu qu'on ne définisse pas d'autre constructeur.
 
 
... enfin quelque chose dans ce genre là

ratai.
 
2 choses :
1)si on défini pas de constructeur, un constructeur public sans argument avec un corps vide est syntétisé
 
2)tout constructeur qui n'appelle pas explicitement un autre constructeur appelle implicitement super(). en générant des erreurs si c'est pas possible, j'ai créé un topic à ce sujet il y a un paquet de temps.

euh le (2) est valide uniquement pour un constructeur sans argument ou bien un constructeur a argument appelle aussi implicitement le super() ???
 
et pour le (1) oui jme suis vautré, par contre les définir dans une class abstraite qu'on étend permet d'obliger le développeurs à définir au - un constructeur, du coup avec un peu de pot s'il est pas trop con il fera appel au bon super(..)

ce qu'a dit nraynaud est valable dans tous les cas

tous les constructeurs appellent donc le super() implecititement, sauf s'ils appellent un autre super(...)

sauf s'ils appellent un autre super() ou un autre this()
 
la logique est simple : on construit l'objet par "étages" en partant du plus concret. Et il est interdit de ne pas construire tous les étages jusqu'à Object, ce qui dans certains cas piège ceux qui ne le savent pas.
 
edit : on construit l'objet par étage, du plus concret jusqu'à Object, en passant soit des this(..) pour rester dans l'étage soit super(...) pour passer à l'étage immédiatement supérieur (je rappelle que les constructeurs ne sont pas hérités donc impossible de sauter des étages, d'autre part ça serait dangereux).