Reprise du message précédent :

j'ai édité ...

t'as oublié le return type

nan, marche tjs pas

 en java ça se fait pas comme ça l'optimisation.
la JVM le fait par boxing elimination et par monomorphic call specialisation.
quand il a fait les 2 il a ouvert la voie à toute la réécriture : inilining, CSE etc.  
 
Le tout en dynamique.

merci de faire des phrases compréhensibles par des humains

 
-- > c'est quoi le message d'erreur ?
 
par contre, c'est pas une spécialisation au sens C++ car en C++ le layout de la classe peut être différent aussi.
 
et on ne fait pas de l'optimisation comme ça en java

 
ah les javeux sont rigolos, y'a un an tu leur parlais de generique, de specialisation ils et disaient que ca servaient a rien, que ca puait, que t'avais qu'a faire de l'objet et ta gueule(y'a object et les ClassCastException ) et vla maintenant qu'ils s'urinent dessus de plaisir parce que Sun, (qu'ils idolatre tous de pitoyable facon) a enfin decider de se bouger le cul (en chiant une syntaxe deguelasse, evidemment, apres avoir attendu 10 ans en se tournant les pouces c'est un peu pas evident de refoutre des nouveaux mots clé dans un langage. Conclusion : ca boite mechamment, vouant ainsi Java a la disparation au profit de quelque chose de mieux pensé des le debut)
 
 
 
 
 

chrisbk> après le coup de l'OS paléolithique, maintenant ça
 
garde en un peu pour le reste de l'année hein.

comment déclencher les passions avec une question toute con....
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
... et la spécialisation partielle de template, ça existe ?

mais je le pense, en plus les "ouahhh les templates du C++, c'est tout laid, pis ca pue", j'en ai lu, et maintenant regarde ce qu'ils ont un truc aussi laid que du C++, mais moins puissant, et qu'et ce qu'ils font ?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
 
ca :

 
 
CSE = Common Subexpression Elimination
 
autrement dit, tu degages les trucs qui se ressemble
 
exemple
 

 
se transformé en

 
tu gagnes en quantité de code, parfois en vitesse, mais tu risque de noyer ton cache de code, bref, y'a du pour y'a du contre. Dans le meme rayon d'idée y'a le Global Value Numbering, plus chiant a faire mais qui  donne de tres chouette resultat, en travaillant par congruence de variable (faut juste avoir un SSA sous la main)
 
l'interet de la chose c'est qu'apres si tu fous un global copy propagation (le prochaine utilisation de a sera remplacé par g, par exemple) tu pourras peut etre carrement supprimer a et b, diminuant la pression qu'aura a subir l'allocateur de registre.
 
Evidemment, des analyses de flow seront necessaire pour savoir ou faire un copy propagation valide.
 
inlining, tout le monde sait c'est quoi
 
monomorphing call spemachin, je connais pas, mais je suppose que c'est compiler plusieurs fois la meme fonction pour un type en entrée donné, histoire que ca bouste plus (en supprimant les appels indirect et permettant donc les optims sus-citée)

sinon pour ta remarque chkribsq, je suis plutot d'accord avec toi.
 
perso, je connais pas les generics du C++, je les ai à peine aperçu, donc je peux pas les critiquer. Les generics java me font un peu peur : c'est sensé être là pour rendre le code plus clair et plus facile à écrire, mais je crains que ce soit l'inverse qui se produise (cf le prob de notre amis posteur et la gueule de la javadoc de java.util.Collections).
 
Pour autant, avant de geuler, je préfère tester, donc ca m'intéresse bien de regarder comment ca fonctionne, de voir les problèmes, mais aussi les avantages qu'on peut en tirer ...  
 
voila voila ... je pouvais pas laisser passer un aussi joli troll sans réagir, ca aurait été du gachi
 
edit : et merci pour la traduction nraynaud->humain  (même si j'ai pas encore tout compris, mais c'est pas grave }

benou >> niveau *utilisation* ça roxxe total en tous cas. merde, plus de cast, plus d'iterator a la con (foreach), y'a pas photo.
apres niveau syntaxe, c'est pas facile. spa une raison pour faire des patés à un chrisbk qui semble visiblement s'ennuyer aujourd'hui.

 
 
cbien de fois je vous l'ai repeté l'an dernier
FAIS DE L'OBJET !

chrisbk > les generics ne sont pas des templates, un generic java c'est bien typé *en soi* et ça ne sert qu'à faire du code générique, ce n'est pas la même chose.
 
benou > oui, les generics mettent au jour des dépendances auxquelles personne ne pensait avant, on va dans le sens de plus d'analyse du code et plus de sécurité. Mais aussi dans le sens de plus de noobs casse-couilles.

benou> voici l'erreur :
The type Integer is not an interface; it cannot be specified as a bounded  
 parameter
 
pour l'intérêt des generics, je dirai comme --, ça peut rendre un code tout pourri, mais à faible dose ça rend bien service.
Parce que les Collection d'Object c'est bien, mais qu'est-ce qu'il faut pas se coltiner comme protection pour être sûr de pas corrompre la collection et du coup on allourdi le code pour rien.
 
Je dirai que c'est comme d'autre technos (les Exceptions, ...) c'est pratique mais va pas vouloir faire que de ça !

sinon, y'a un équivalent Java de dynamic_cast ?

 
 
ski faut pas lire
 

quel est son intérêt ?
J'ai jamais utilisé ça

 
 
le dynamic_cast du C++ == le cast du java
 
bravo harko

chrisbk> ha d'accord ! ça part en troll, stou ...

ouais, ca va TT si ca continue

 
j'ai pas vu de troll dans la question d'harko, juste une question con

bha, tiens ... pkoi on pourrait pas bounder avec une classe  

parce que l'erasure réelle sera une interface qui va étendre toutes les bounds ?  
 
(j'ai pas la spec là pour vérifier)

bon, je continuerai à poster dans ce topic après avoir lu la doc

benou> Entre nous l'exemple serait-il pas un peu foireux ?
car Integer hérite bien de Number ? donc à quoi bon vouloir que SI soit un sous-type de T (qui est un sous-type de Number) et de Integer ?
<SI extends Integer> suffit ? non ?

c'était pour le cas où tu utilisais une sous-classe de Integer comme type générique, mais j'avais aucune certitude sur le fait que ca fonctionne ...

 
 
( j'avoue - mais les trucs dont je parle là sont fortement typés c tres objet )

c'est sympa aussi sur un ThreadLocal

\o/

si si, c'en était un

 
 
 
T1 j'ai du me coltiner les 70 posts !   .
 
 
 
Bon dejà Benou, ton exemple avec les ArrayList est un peu pourri car ArrayList n'implemente meme pas l'interface Set . Bref c'est un détail.
 
 
 
Sinon pour bobuse, effectivement j'ai essaié comme tu as dis, c'est à dire au lieu de mettre la signature  
 

 
 
 
j'ai mis  
 

 
 
 
Comme de toute façon je n'utilise que les méthodes de l'interface Set, je me dis OK, ca fera l'affaire pareil.
 
Donc si je réécris mon code de la fonction "grapheIdeaux" ça me donne (je vire simplement tous les "? extends":
 

 
 
 
et maintenant tout compile . MAIS...
 
De retour dans mon main j'écris :
 
 
 

 
Bref, mon main compile plus : message d'erreur :

 
et le pire c'est que je ne comprends pas pourquoi parce que ma clé "TreeSet<Integer>" est bien un "Set" que je sache   .
 
Par contre si je remets ma cle avec "? extends Set<T>", au prototype de départ de la fonction grapheIdeaux, mon main passe .
 
Pour information, voici la signature de topologicSort() :

 
Bref, j'attends toujours une proposition comment résoudre cette merde

 
 
Je l'ai toute lue ta doc sur les generic-type meme celle aussi de developpez.com. Le problème c'est que ces docs ne vont pas loin du tout a mon gout ! En gros elles se contentent d'expliquer seulement les generic sur des cas trivial. Sorti de la, la doc te dis d'aller voir ailleurs pour kkchose de plus pointu sur les generic dommage.

ben ma solution a moi doit fonctionner ... comme je le disais, la solution de Bobuse est trop restrictive : elle ne marche qu'avec des Set<T> => tu ne peux pas l'utiliser avec un TreeSet<T>.
 
et c'est vrai pour mon exemple avec la ArrayList, mais t'as compris ce que je voulais dire : si tu utilises une classe de Set (ce que tu fais), tu t'aperçois que ca marche pas

ben pourtant je crois bien avoir compris ton problême en lisant les premiers chapitres de cette doc, moi    
 
teste mon truc (avec le type générique B), je pense vraiment que ca doit passer !!

 
Tu ne peux pas !
section 3 du tut de sun (page 4)
section "les generics ne sont pas des templates" du tut de dev.com
un objet de type (uneClasse<A> ) ne peut pas être affecté à une variable de type (uneClasse<B> ), même si A hérite de B.

ca marche mon truc ou pas ?

ha ba oui, parce que moi sinon je récupère mes patates