Mes arguments ils sont tout simple :
Quel est l'intérêt des templates, plutôt qu'une classe de base CObject, surchargée par tous les éléments d'une API ? Pourrir la lisibilité du code ?
Et puis, cela mis à part, la STL n'est quand même pas tellement lisible je trouve.  
En STL, on dirait que le code à été volontairement compliqué, des trucs tout bête avec les MFC sont vachement plus complexes à écrire en STL. Et puis j'ai trouvé aucune doc attrayante sur le STL, ça me saoule.

 
heu....
 
les templates et partir d'une classe de base ça n'a rien à voir mais rien à voir du tout.

 
ben disons que les 2 permettent d'*crire des conteurs g*n*riques par exemple.
En Java, les classes Vector, ArrayList, etc... contiennent des instances de type Object. Ensuite on caste comme bon nous semble.

 
ben disons que les 2 permettent d'écrire des conteurs génériques par exemple.
En Java, les classes Vector, ArrayList, etc... contiennent des instances de type Object. Ensuite on caste comme bon nous semble.

 
D'ailleur je comprends pas pourquoi ils ont inventé les langages statiquement typés alors que smalltalk marche très bien entre 2 "Message not understood".
 

au lieu de blablatter tu devrais me filer des liens pour que je commence à apprendre le smalltalk ou tout autre langage que tu tiens en haute estime

Tiens, puisque j'ai des pross de la STL sous la main ;
 
int num = 25;
std::string maStr = "toto";
 
Comment faire pour concatener num à maStr ?
 
 

http://www.cmla.ens-cachan.fr/Util [...] ree_sortie

Je blablate pas, je pose implicitement la question suivante : pourquoi le langage serait en partie statiquement typé et en partie dynamiquement typé ?

Il s'avère que l'industrie préfère les langages à typage fort.

Il s'avère que l'industrie préfère les langages à typage fort. C'est en tout cas la raison principale qui explique le faible succès de SmallTalk dans l'industrie.
C'est un choix qui se défend (disposer d'outils capables, dès la compilation, de détecter le maximum d'erreurs), mais je reconnais que le gros de l'industrie n'est pas allée jusqu'au bout de cette logique (sinon, le langage le plus répandu aujourd'hui serait Ada).

 
Alors si c'est typé statiquement à certains endroit, pourquoi certains défendent la roulette russe (le downcast) en sortie de collection ?? Alors qu'il existe des notations tout à fait appropriées.

En C++, j'en sais rien. Apparement, si !?

 
En Java, le downcast n'a rien à voir avec la roulette Russe. En C++, j'en sais rien. Apparement, si !?

Je blablate pas, je pose implicitement la question suivante : pourquoi le langage serait en partie statiquement typé et en partie dynamiquement typé ?

 
parce que parfois on a besoin d'etre statiquement type et d'autres fois dynamiquement ?
 
Parce que tout n'est ni tout blanc ni tout noir?
 
LeGreg

 
T'as pourtant aucune garantie qu'il va pas te pêter un ClassCastBidule.  
Alors qu'il existe des systèmes où tu ne peux pas rentrer un objet du mauvais type dans ta collection.

 
T'as pourtant aucune garantie qu'il va pas te pêter un ClassCastBidule.  
Alors qu'il existe des systèmes où tu ne peux pas rentrer un objet du mauvais type dans ta collection.

En Java, un cast n'est jamais gratuit * l'ex*cution : avant de faire effectivement le cast, la machine virtuelle que l'objet a effectivement le type demand*. Et si ce n'est pas le cas, *a t'explose * la figure avec une ClassCastException.
 
Par contre, c'est vrai, puisqu'une collection est toujours faite d'instances d'Object, rien ne te garantit que tu ne vas pas ajouter des voitures * ta collection de Personnes. C'est * cela que la g*n*ricit*, qui devrait apparaitre dans le JDK 1.5, rem*diera.
 
Mais tu noteras que SmallTalk en l'occurrence ne fait pas mieux que Java aujourd'hui...

En Java, un cast n'est jamais gratuit à l'exécution : avant de faire effectivement le cast, la machine virtuelle que l'objet a effectivement le type demandé. Et si ce n'est pas le cas, ça t'explose à la figure avec une ClassCastException.
 
Par contre, c'est vrai, puisqu'une collection est toujours faite d'instances d'Object, rien ne te garantit que tu ne vas pas ajouter des voitures à ta collection de Personnes. C'est à cela que la généricité, qui devrait apparaitre dans le JDK 1.5, remédiera.
 
Mais tu noteras que SmallTalk en l'occurrence ne fait pas mieux que Java aujourd'hui...

En Java, un cast n'est jamais gratuit à l'exécution : avant de faire effectivement le cast, la machine virtuelle que l'objet a effectivement le type demandé. Et si ce n'est pas le cas, ça t'explose à la figure avec une ClassCastException.
 
Par contre, c'est vrai, puisqu'une collection est toujours faite d'instances d'Object, rien ne te garantit que tu ne vas pas ajouter des voitures à ta collection de Personnes. C'est à cela que la généricité, qui devrait apparaitre dans le JDK 1.5, remédiera.
 
Mais tu noteras que SmallTalk en l'occurrence ne fait pas mieux que Java aujourd'hui...

 
Ben, justement, ça se catch une ClassCastException !

 
et tu fais quoi une dans la clause catch en question ? tu tentes toute une série de cast jusqu'à ce qu'il y en ait un qui marche ?
 
Ca me fait penser à ce repas un peu arrosé où avec un pote on songeait à modifier la méthode doesNotUnderstand: afin de retenter l'appel avec les même argument sur un autre sélecteur jusqu'à ce que ça marche.

Et sur quelle base repose la frontière ?

En fait, l'inconvénient des templates, selon moi, c'est que ceux-ci devraient être plus restrictifs. dans vector<MaClasse>, on ne devrait pour pouvoir fouttre ce qu'on veut, mais par exemlpe, uniquement des classes implémentant une classe purement abstraite (interface), guarantissant ainsi que la classes dispose bien des opérateurs nécessaires.

 
Ben non, pour reproduire le comportement des templates : si l'instance récupérée n'est pas du type attendu : erreur. Sauf que l'erreur n'est pas à la compil, mais à l'execution.

En fait, l'inconv*nient des templates, selon moi, c'est que ceux-ci devraient *tre plus restrictifs. dans vector<MaClasse>, on ne devrait pour pouvoir fouttre ce qu'on veut, mais par exemlpe, uniquement des classes impl*mentant une classe purement abstraite (interface), guarantissant ainsi que la classes dispose bien des op*rateurs n*cessaires.

 
Donc ça plantera dans 10 ans, chez le client, quand plus personne ne saura rien sur ce projet. C'est un peu comme du C finalement : tu écrit un bug (une connerie sur la mémoire par ex.) ça marche nickel pendant les tests et ça plante chez le client 10 ans plus tard.
 
C'est une avancée indéniable.

 
Je ne comprends pas ton probleme la. Que je sache, en ecrivant vector<MaClass *>, tu ne peux mettre dans ton vector que des classes heritant de MaClass. Si tu veux faire une interface comme en Java, il y a l'heritage multiple pour cela et to vecteur s'ecrit alors vector<MonInterface *>

 
...rien à voir. On catch l'exception, on connait donc la source exacte de l'erreur, et on évite un plantage.

 
Non, en effet, tu comprends pas mon problème !
Ce que je veux dire, c'est que, vu que Vector nécessite que les classes qu'il contient aient un opérateur = valide, et un constructeur de copie, ce serai bien que, au moment ou on crée le template, on puisse limiter le type de classes qu'il peut utiliser, aux classes implémentant operator= et le constructeur de copie.

 
Non, en effet, tu comprends pas mon problème !
Ce que je veux dire, c'est que, vu que Vector nécessite que les classes qu'il contient aient un opérateur = valide, et un constructeur de copie, ce serai bien que, au moment ou on crée le template, on puisse limiter le type de classes qu'il peut utiliser, aux classes implémentant operator= et le constructeur de copie.

 
Non, en effet, tu comprends pas mon probl*me !
Ce que je veux dire, c'est que, vu que Vector n*cessite que les classes qu'il contient aient un op*rateur = valide, et un constructeur de copie, ce serai bien que, au moment ou on cr*e le template, on puisse limiter le type de classes qu'il peut utiliser, aux classes impl*mentant operator= et le constructeur de copie.

Tu m'as toujours pas dit ce que tu mettais dans la clause catch comme code. Si ton cast échoue, c'est un bug (je parle du cas typique de la sortie de collection), as-tu un morceau ce code magique pour rattraper le coup lorsqu'un bug c'est déjà produit ?  
Veux-tu partager ce lourd secret avec nous ?
 
Plus sérieusement, je ne vois pas en quoi trapper l'exception est utile, si elle se produit tu laisses courrir, le truc se plante le débugger rattrape et tu peux chercher la connerie, mais si c'est en prod, c'est la merde.
 
Peux-tu donner un exemple ?

Ben, le catch, ça te permet de logger l'erreur. Si l'objet dans la liste n'est pas de la classes censée y être, il faut considèrer qu'il n'y est pas, tout simplement !