'lut
 
juste une question d'optimisation et de propreté du code (car les 2 marchent), mais entre:

et

 
qu'est-ce qui est le mieux d'après vous ?
 
d'après la javadoc:

 
donc je dirais que c'est strictement la même chose, mais il y a peutetre des choses que je ne maitrise pas totalement.
 
merci d'avance

je te conseille ValueOf(), qui ne construit pas forcément d'objet. s'il veut, il peut réutiliser des objets dans ton dos (mais je ne coirs pas que ce soit le cas).
 
pour la classe String, c'est plus stratégique, car en utilisant String.valueOf(variable) au lieu de variable.toString(), tu es sûr de ne jamais avoir une NullPointerException si variable est null.

ok. merci pour le conseil. je pensai en effet à une optimisation du style "pas de construction d'objet". quant à la même question appliquée à String, et bien c'est tjs bon à savoir

heu mais je viens de capter, pourquoi tu n'utilise pas
 
new Integer(0);
 
sans passer par une string ?

Et pourquoi tu n'utilises pas l'autoboxing ?  

C'est utilisable depuis la version Tiger (5.0) de java. Donc attention si tu utilises une version antérieure.

 
le code que j'ai passé est un exemple, je me suis simplement posé cette question au moment où je parcourais les méthodes de Integer
sinon, en effet, new Integer(0) fonctionne aussi. quelle différence fais-tu avec new Integer("0" ) ? (là encore c'est une question d'optimisation, pour "comprendre" )
 
quant à l'autoboxing, sans façon. je travaille encore avec le jdk 1.3.1. je vais peutetre passer au 1.4, et encore c'est simplement parceque les regex m'intéressent...

Dans java il y a deux manière de représenter les entiers, une avec le type primitif int et une avec l'objet Integer.
 
L'objet Integer est en fait un int avec une envellope externe (wrapper), donc le constructeur le plus rapide est "new Integer(138)", si tu met new Integer("138" ), le systeme est obligé d'analyser la chaine de caractère "138", d'en extraire l'entier 138 pour ensuite le mettre dans l'objet Integer, pareil pour Integer.valueof, tandis que  "new Integer(138)" n'implique aucune conversion de type (138 est deja un int), il peut construire l'objet Integer directement.  
 
Si tu tapes le code de grimgroth tu verras qu'il y a des erreurs, en effet, depuis java 5.0 il faut dire au systeme si on construit un vector de string, ou un vector d'entier etc...
 
Donc moi j'écrirais plutot:
 

 
PS: J'avais pas vu que t'étais encore à java 1.4, oublie cette histoire de <>.

 
c'est bien ce que je pensais, mais je voulais etre sur. même si les 2 solutions marchent, j'ai besoin de ce genre d'optimisation, deja pour m'améliorer globalement, et puis pour améliorer mon code, car j'utilise ce genre de choses dans un algo type backpack, dont le temps de traitement est gravement exponentiel: de 1-2 secondes pour 15 entrées, à au moins 20 secondes pour une 30aine... sachant que mon programme est prévu pour tourner avec plus d'une centaine d'entrées - plus de 800 dans mon cas - ca donne une idée du temps de traitement globale :\. donc je cherche à optimiser au mieux

on peu voir le code ?  
par ce que je suis pas sûr que ce soit là-dessus que tu vas gagner ...

Faut se méfier des optimisations "qui semblent logiques"...

voilà... je demanderai votre indulgence si des abberrations vous sautent aux yeux, ce code est en cours de développement - mais le code est tout de même fctnnel :

 
détails:
- l'idée est d'appliquer l'algo backpack plusieurs fois sur une liste d'éléments (tailleReps) afin de déterminer plusieurs sac-à-dos (en l'occurrence plusieurs cds de mp3)
- l'algo backpack a été implémenté en utilisant une fonction récursive (basé sur l'algo donné ICI)
- ces différents sac-à-dos trouvés sont stockés à la fois dans meilleurCd (pour le traitement récursif de l'algo backpack), dans posReps (pour la sauvegarde de la bonne solution - je pense pouvoir me passer de cet attribut, mais pour le moment il est là), et au final dans cdsMp3 ("inverse" de posReps: à chaque cd est associé l'Id des répertoires qui le constituent)
- les répertoires (enfin leurs capacités) sont issus d'une bdd, où sont associés un Id (col 1) et la taille en octets (col 2)
- la taille du média spécifiée par l'utilisateur est récupérée d'un ensemble de paramètres stockés dans une classe dont l'instance utilisée ici est params
 
nda: il s'agit de mp3 créés à partir de ma discothèque personnelle, le but étant de créer des cds spécifiquement pour ma discothèque de voiture

j'ai pas encore lu mais l'idée d'utiliser cet algo pour ç aest intéressante.
 
par contre tes perfs sont innaceptables.

http://www.enseignement.polytechni [...] e.html#310
tu as regardé du côté de ça ? peut-être que ça marche aussi avec des grands entiers (taille des répertoires en octets).

bah j'ai donné le code parce qu'on me l'a proposé. je peux très bien comprendre qu'on ait ni le temps ni l'envie de se plonger le nez dedans - et en + j'ai quand même essayé de garder uniquement les choses nécessaires...
 
je viens de refaire plusieurs tests (au moins 2x pour chaque) montre-en-main:
- 53s pour une liste de 29 reps
- 11s pour 25 reps
- 2-3s pour 20 reps
 
:\

 
non pas encore. je cherchais justement un algo type backpack pour les entiers, car j'ai lu, à la fois sur ce site, et ailleurs, que ce pb est non-polynomial dans le cas où la capacité est réelle. or, dans mon cas, en effet elle est entière.
j'ai cherché un peu - certainement mal - mais n'ai pas trouvé d'éléments de solutions - ou d'éléments de solutions que je comprenne en tout cas
 
en revanche, sur le lien que tu donnes, il n'y a qu'une ligne, c'est normal ? je n'ai pas retrouvé cette ligne sur le site. de quel page est extraite cette info stp ?
 
(merci de m'aider au fait )

sur la page que tu as donnévers le milieu.

 
ah oui, chez moi (opera) l'image du lien n'est pas affiché, je croyais que c'était juste une image sans lien. voilà pourquoi je ne l'avais pas lu
ca confirme donc ce que j'avais cru comprendre. je vais donc me pencher sur cette programmation dynamique