Reprise du message précédent :

 
Donc tu sais que tu as une donnée invalide dans un ensemble. Tu ignore tout de l'intégrité de tes données (et honnetement, il y aurait de quoi douter) et tu oses continuer comme si de rien était ?
 

 
Finalement, smalltalk c'est pas si mal, tout dépends de tes règles à toi :-)

 
Oui, bien sur, 'faut être cool dans la vie !
Qui ne tente rien n'a rien, de toute façon, l'erreur est loguée. Autant essayer de continuer le traitement, il a toujours + de chances de réussir que si on l'arrête.

Si tu es un programmeur très stupide, oui.
Mais dans la prtaique, ça n'arrive jamais. Alors tu sors en erreur, soit en laissant se propager cette exception jusqu'au point d'entrée (main ou servlet), quitte, au passage, à laisser une trace dans un log d'exécution si tu en utilises un.
 
Pourquoi ça n'arrive jamais ? Parce que les programmeurs Java ne sont pas cons à ce point... S'ils ont un doute sur le type de l'objet qu'ils récupèrent (ce qui arrive rarement, mais ce qui arrive quand même), ils font un "instanceof" avant pourtester le type de l'objet...  

Je suis bien d'accord. En C++, il faut, au mieux, attendre l'édition de liens pour savoir qu'il manque une fonction sur un type que tu utilises pour instancier une classe template. Et le message d'erreur n'est pas des plus clairs ! Parfois même (en particulier dans le cas des constructeurs par recopie), le compilateur a généré automatiquement une implémentation qui ne convient pas ; résultat : tout compile, et à l'exécution, ça fonctionne, mais seulement dans 99 cas sur 100...  
 
Java ne devrait pas avoir ce souci car on devrait pouvoir écrire

D'ailleurs, tu peux déjà les utiliser : Sun fournit un "patch" pour le JDK 1.4.1 qui modifie le compilateur Java et accepter les génériques.
 
Quelques URLs:

• http://developer.java.sun.com/deve [...] /generics/
• http://servlet.java.sun.com/javaon [...] sf2001.jsp
• http://java.sun.com/javaone/javaone2001/pdfs/2733.pdf

 
S'ils étaient un peu moins cons encore, ils auraient mis une précondition sur le type des objets de la collection. Et s'ils l'étaient encore moins, ils auraient déjà leur généricité.

On est en 2003, mais y'a 20 ans une classe mere Object n'a pas ete implemente dans le langage pour des problemes de performance.
 
En effet le C++ a ete concu de tel sorte qu'il puisse remplacer le C, donc il a fallu eliminer des concepts pour garder la vitesse d'execution proche du C sinon les developpeurs auraient hesites a passer au C++.
 
Pourquoi une classe mere Object prendrait plus de ressource ?
ba deja y'a heritage, donc tu trimbales plein de trucs.
ensuite il faudrait que les methodes de cette classe soit en virtual pour pouvoir les redefinir -> creation d'une table d'index qui prend aussi plein de ressource.
 
D'ailleurs pourquoi en C++ on doit indiquer virtual pour avoir le typage dynamique contrairement au Java ou toutes les methodes sont virtual par defaut ? ba ca prend trop de ressources.
 
En Java ils ont concu le langage sans avoir les perfomances en 1er objectif mais la facilite.
 
Donc pour avoir la genericite que l'on pouvait obtenir avec la classe Object, ils ont concu les templates.
Creer une classe template c'est assez complexe et les templates ont des limitations (pas de virtual, message immonde en cas d'erreur lors de la compil, dans les headers sauf avec export...), et la syntaxe est assez complexe.
Par contre ca a l'avantage de pas devoir faire des cast comme avec une classe Object, et les cast tout le monde le sait, moins on en a et mieux on se porte.
 
Mais en revanche je suis pas du tout d'accord pour la complexite de la STL.
 
La STL (qui rappelont le a ete soumis pour etre inclus au langage en 1994 et est donc standard dans le langage maintenant) est certainement la meilleure chose qui soit arrive au C++.
 
C'est super super super bien foutu, en une poigne de classes (la STL est tres petite si on regarde bien) on peut faire des choses extremement diversifies, generiques (avec les iterator) et puissantes.
 
Y'a juste a apprendre 2-3 trucs et c'est bon, tout s'appuie sur les memes choses.
Avec les typedef on ne voit pas la syntaxe des templates
 
Y'a un excelent chapitre sur la STL dans le 2e volume de thinking in C++ de Bruce Eckel disponible gratuitement en ligne sur www.bruceeckel.com
Pour comprendre la beaute, la puissance et l'elegance de la chose !
 
Pour moi le C++ sans STL c'est meme pas du C++

 
et la marmotte ?
 
tiens : http://nraynaud.com.free.fr/types.html
une petite remise à niveau sur les types.
 
Le C++ n'a pas inventé les templates, ça existait avant (ce qui n'enlève rien à C++, c'est une remarque factuelle). Ils ont juste mis ça dedans.  
 
J'ai cheché un peu dans le Meyer mais j'ai pas trouvé l'origine de la généricité, juste que Ada l'avait en 83.

 
T'as tres bien compris ce que je voulais dire, comme tout le monde d'ailleurs.

moi je t'ai bien compris. Surtout quand tu dis du bien du C++

 
non, y'a des opérateurs de casting des plus exotiques dans C++ qui, j'en suis sûr, mimerons très bien la partie la plus merdique de java.
 
D'autre part, concernant l'absence de super-classe commune à toutes les classes, ça veut dire qu'elles n'ont aucune interface commune (puisque sinon, elle serait factorisée par une super-classe commune) hors il existe un certain comportement commun à toutes les classes : l'affectation et le constructeur par copie (heu, y'en au peut-être d'autre, j'ai pas ça en tête). En particuler, la possibilité de faire un = sur n'importe quel objet (j'ai pas dit variable, puisqu'elle peut-être statique), signifie qu'il existe, ce comportement commun. Comportement qui est, je trouve extrèmement présomptueux.
 
On voit donc 2 choses :  
- il existe un piège à con, un comportement commun non documenté par la technique standard (une classe). Qu'on se rassure, c'est pas le seul piège à con du C++  (par exemple l'appel du constructeur par copie dans certains cas alors que visuellement c'est un signe d'affectation qui est inscrit).
- des méthodes à liaison retardée dans une super-classe commune n'est pas la seule technique pour s'assurer de la présence d'un comportement commun à toutes les classes, puisque dans le cas de C++ c'est la génération de code "à la demande" et "par défaut" qui a été retenue.

 
Je crois que dans ta piole il doit plus rester beaucoup de moquette
 
Les concepteurs de C++ ont decides d'utiliser la solution template par rapport a une classe mere parceque cette solution bouffait trop de ressources.
 
Ca repondait tout simplement a la question de El_gringo qui se demandait pourquoi ils n'avaient pas utiliser une classe Object
 
C'est si compliquer que ca a comprendre ?

 
Comme nraynaud, je trouve ça bizarre comme explication. Tu as des pointeurs webographiques ou bibliographiques qui confirment ?

Non, s'ils étaient encore moins cons, ils n'auraient pas besoin de tester le type réel de leur objet. Mais ça, c'est un problème d'architecture, ni plus ni moins.
Maintenant, tu ne peux pas accuser les programmeurs Java de ne pas utiliser des fonctionnalités qui n'existent pas dans le langage et dont l'intégration requiert la modification de la syntaxe du langage : en l'occurrence, les assertions sont encore toutes récentes, et la généricité n'est pas encore standard dans le langage.

Dommage que tu ne parles pas d'Ada dans ta page, car il y trouve naturellement sa place.
 
Sinon, je sais que les concepteurs d'Ada se sont inspirés de Simula pour beaucoup de concepts. Mais je ne connais pas du tout ce dernier. Peut-être contient (au moins) un embryon de généricité. Mais à ma connaissance, les concepteurs d'Ada revendiquaient n'avoir rien inventé dans Ada, mais seulement avoir rassemblé dans un langage unique le meilleur de tout ce qu'on avait fait jusque-là en matière de langage de programmation. Donc la généricité doit avoir été inventée avant Ada.

ça dévie en combat de langages là, y a un topic pour ça

A mon avis, c'est un raisonnement erroné. D'abord parce que les templates en C++ sont bien postérieurs à C++ lui-même. D'autre part, il ne faut pas oublier la philosophie fondamentale et originelle de C++ : "C with classes". En clair, il faut que l'on puisse faire du C avec un peu d'objet pour enrober. En particulier, en C++, on peut écrire des classes sans jamais utiliser le mécanisme d'héritage.
Or la solution classe Object ancêtre de toutes les autres classes contredit cet objectif originel, en forçant l'usage de beaucoup de concepts objet d'un seul coup (en particulier, donc, l'héritage). Et de nombreuses fonctions qui ne sont pas virtuelles dans les classes C++ aujourd'hui l'auraient nécessairement été avec une classe ancêtre unique.
 
Pourquoi ne pas vouloir utiliser l'héritage ? Effectivement, comme l'a souligné tanguy, pour ne pas se couper des programmeurs C, "coeur de cible" principal de C++ à ses débuts. Or typiquement, ces programmeurs-là sont obnubilés par l'efficacité supposée de leur programme. Il fallait donc leur "donner des gages", en leur offrant la possibilité de "déconnecter" tout ou partie des mécanismes supplémentaires qu'impose l'objet.

On ne se bat pas !  

La philosophie du C++ serait plustot : "Tu ne payes pas le coup de ce que tu n'utilises pas". Et sur ce point, le langage est bien fait
 
Edit : Je parle du coup d'execution ou de consomation memoire bien sur ...

 
Je n'avais pas encore étudié Ada à l'époque.
 
Concernant Simula, d'après ce que j'ai vu dans le Meyer, il ressemble plutôt à Smalltalk (j'ai l'impression qu'il n'est pas statiquement typé).

 
Naturellement, car le coût de maintenance et de développement ...

Dans ces domaines-là, ce que tu payes, c'est le coup de massue ! (et non le coût de la massue)

 
Quand est-ce que tu nous réécris KDE en smalltalk ?

 
1) faire maintenir un bloatware par des bénévoles, c'est difficile à chiffrer
 
2) smalltalk est une catastrophe en maintenance, il ne doit servir qu'à la pédagogie, où il est un des champions (c'est pourquoi j'en parle souvent lors des discussions).
 
edit :
 
3) smalltalk était un gestionnaire de fenêtre + un framework complet d'exécution + tout un tas de bordel longtemps avant KDE.
 
4) KDE n'est pas développé par une seule personne

Eh oui, le C++ sans templates a au moins l'intérêt de garder tous les avantages du C, c'est à dire sa rapidité d'exécution, le programmeur reste proche de la machine et sait exactement ce qui s'y passe.
C'est une étape de + après le passage de l'ASM au C, pour garder les performances tout en structurant davantage et en facilitant le développement en équipe.
Si on va trop loin avec les objets c'est plus le même langage, et ça ne sert plus à la même chose.
Dans le domaine du temps réel (jeu), du calcul (image de synthèse), ou des systèmes d'exploitation, qui sont quand-même largement utilisés sur PC, c'est du délire d'utiliser un langage abstrait.
Dans ces domaines on DOIT avoir un moyen de voir tout ce que fait la machine, donc le contenu de toute classe ou fonction utilisée.
Dans le jeu vidéo (mon domaine), j'ai toujours gerbé sur beaucoup de choses qu'on entend ici (cette critique n'est valable que dans ce cas, je gerbe pas du tout sur le topic:D). Le genre de truc qui fait bosser la machine ou qui bouffe de la RAM (même très peu) sans qu'on sache comment ni pourquoi c'est interdit.
D'ailleurs c'est quand-même très bénéfique pour le résultat de toujours bien savoir ce qu'il se passe dans chaque partie du programme.
J'ai vu des critiques sur les cast, franchement si c'est pas fait n'importe comment je trouve pas ça dangereux.
C'est bien de vouloir parler un autre langage que la machine, mais il faut quand-même qu'elle arrive à peu près à comprendre ce qu'on veut sans faire 10 fois le boulot nécessaire.
Donc dans certains domaines: la STL rend le programme illisible et ne sert qu'à perdre le contrôle de ce qui se passe.
Je suis pas sûr que ce genre de choses n'ai pas alourdi énormément les OS qu'on utilise...
 
Apparemment dans d'autres situations c'est (très?) utile, d'après ce que je lis ici...

Alors comme ca, tu penses pouvoir faire mieux que la STL en terme de performance ? Alors vas-y, prouve le !

J'ai pas pigé le rapport entre la STL et les OS alourdis ...
Je crois que tu ne connais pas très bien les templates / la STL.
Dans ton domaine justement, j'ai rencontré un jour un programmeur de jeux videos. A l'époque, j'étais pas très copain avec le C++, un peu comme tu sembles l'être maintenant.
Il bossait alors sous PS2. Il m'a dit texto "les templates C++, c'est le top"
Tu serais surpris si tu t'y intéressait vraiment, comme je l'ai été. Il suffit de tester. J'avais fait un prog en 2 versions. Une STL et l'autre en C. La version STL était déjà bcp plus lisible. Vire le code de gestion mémoire, utilise des fonctions telles que swap, find, ... et tu commences déjà à être séduit.
Puis j'ai compilé et testé.
Mon code C était 3 fois plus rapide. J'étais surpris que la différence ne soit pas + élevée, car le code était vraiment au désaventage de la STL.
J'avais testé sous VC++ 6... sachant la STL de MS réputée merdique, j'ai téléchargé celle de SGI. Et la badaboum, le traumatisme. Code C a peine, mais à peine plus rapide. Voire meme comparable !
Et du code STL peut etre plus rapide que du C.
ex, on trouve souvent cela en C :

Eh ben l'équivalent STL est + rapide !

En C, strlen va parcourir toute la chaine pour trouver '\0'.
Avec la STL (implémentation efficace biensur), la longueur est contenue dans un champ ... => simple affectation. Et comme c'est du code inline ...
Et le code STL est aussi + sûr. Si tu dépasses les bornes de ton vector en debug, hop, assertion failed et un bug tout de suite repéré.
Evidement le C est généralement meilleur. Mais quand meme.
Bien utilisée, la STL peut etre surprenante. Le gain en lisibilité vaut largement la faible perte de vitesse.
un reserve() bien placé, et le tour et joué.
Et puis avec des implémentations COW on peut arriver à des petites merveilles.

De toute façon, il suffit de comparer le sort de la STL avec le qsort du C et on n'est pas déçus
 
Les perfs de la version STL sont bien meilleures

Ben Wave, tu programmes sur GBA ?
Même SN supporte les templates du C++.
 
Le seul probleme des templates dans une utilisation
au jour le jour que je vois, ne sont pas des problemes
de performances (je ne te parle pas de STL ici) mais des problemes lies a leurs implementations. Notamment l'exportation de classes templates via une dll (vous savez le petit warning que vous disabliez sous VC6.. et bien c'est devenu une erreur sous VC7..), ou les codes qui sont legaux du point de vue du standard et qui font planter le compilateur.
 
De meme l'utilisation de la STL au jour le jour peche par ses implementations douteuses et la syntaxe du C++ qui differe d'un compilateur a un autre mais cela se pose uniquement si vous faites du code cross-compilable. (et chose marrante: l'on ne peut pas exporter une classe qui derive d'un std::map ou d'un std::set.. Parfois rien que d'y penser j'en sue..)
 
Sinon j'ai vote la STL c'est bon mangez-en. Avec un grain de sel, malheureusement.
 
LeGreg

 
Dans ma boite actuelle on utilise stl port pour compiler des serveurs sous windows, solaris, hp-ux, aix et linux. L'experience montre que ca marche pas trop mal et ce sans restriction particulière des possibilités de la stl.

 
Et il supporte SN, metrowerks, et le compilateur Xbox aussi ?
Et tu peux mixer ta version de la STL avec celle qu'utilise le client ?
Et tu exportes des std::map dans des dlls ?
Et tes objets templates sont-ils arkifies (dont les champs sont accessibles par des metafields) et facilement serialisables?
 
LeGreg

 
qu'il est méchant lui    
 
la stl port prcure une portabilité pour les trucs sur lesquels je bosse, et c'est déjà pas mal.
 
C'est sur qu'avec le compilo C++ version alpha 0.34.12-3 pour VMS ca risque de moins bien marcher  

 
Toi tu critiques pas VMS sinon je me fache tout rouge ! C'est compris ?

 
Il n'y a plus longtemps à tenir, l'OS est encore supporté pour 5 ans au dernières nouvelles. Les pauvres bougres qui sont obligés de maintenir des softs là dessus pour gagner leur croute voient enfin le bout du tunnel.

 
au moins tu ne peux pas pretendre qu'il n'y a pas de problemes.
 
Et que l'on n'utilise pas la STL dans ma boite  
est le fait de vrais problemes et non pas parce qu'on n'a pas
suffisamment cherche.  
enfin la plupart des choix de notre architecture ont ete faits avant que j'arrive et j'avoue que je ne comprends pas tout (dans le bon sens: il y a des betes de C++ et je ne peux pas imaginer tous les problemes qu'ils ont eu a gerer)..
 
LeGreg

Les vrais problèmes de la STL sont les même que ceux du C++ en général :
- Les compilateurs ne sont pas cohérents entre eux ce qui complique le portage. Bien surn comme g++ est disponible sur un grand nombre d'architectures ça devrait aller maintenant.
- Il faut une grande experience de la STL pour ne pas faire d'erreures qui peuvent couter cher en temps de developement. Il ne suffit pas d'avoir 1 pro ou deux dans l'equipe, il faut que toute l'equipe s'y connaisse.
 
Moi, je ne peux que conseiller comme livre de chevet ceux de Scott Meyers . Par exemple pour la STL : http://www.awprofessional.com/cata [...] 24DFA675D}

La STL illisible ? C'est comme toutes les nouveautés: quand on découvre on est un peu perdu.
D'ailleurs, ce bout de code est-il illisible pour vous ?
 

 
Si vous n'avez pas remarqué, ça "enlève" les espaces à la fin d'un buffer (c'est pas moi qui est décidé le format du buffer). L'objectif est d'utiliser un algo générique de la STL. Est-ce plus clair de faire le code à la main (avec une boucle "while" ) pour vous ?

 
je me fais l'avocat du diable, mais très honnetement, oui:

c'est plus court à taper, à lire, et sans doute à comprendre (chuis ptet un peu déformé). Par contre faut sans doute être plus vigilant aux bugs qu'avec la version stl

Je regrette, mais ton bout de code, ad-hoc, est beaucoup moins lisible.
Quels sont les critères ? Très simple : pour comprendre, ou pire, vérifier ton propre bout de code, le lecteur est obligé d'exécuter mentalement la boucle. Combien de temps pour un bon programmeur C ? Au bas mot, au moins une minute, s'il veut inclure la plupart des cas un peu tordus dans ses vérifications.
A côté, la séquence STL n'est qu'un problème de connaissance de l'API. Tu t'y réfères, et tu comprends. Et pour vérifier l'exactitude du code, ben en fait, tu n'as quasiment rien à vérifier, le compilateur fait l'essentiel.
 
Tu noteras au passage que ce type de bout de code en pur C, en plus d'être beaucoup moins lisible, est nettement moins évolutif. En particulier, ces bouts de code supposent que les chaînes sont terminées par un caractère zéro, et qu'elles sont composées de caractères ASCII (pour le support des caractères non ouest-européens, on peut aller se rhabiller). Et, cerise sur le gâteau (ton bout de code est un contre-exemple), une fois sur deux, ils contiennent des bugs intrinsèques au langage C, par exemple celui du débordement de buffer.  

Dans un cas comme dans l'autre, quand on se retrouve avec un truc qui parrait impressionant / illisible (qui le sera ou non en fonction de chacun), il y a les commentaires ...
un simple /* remove last spaces in buffer */ et ca va mieux.
Moi ce que j'apprecie dans la STL, c'est qu'on utilise pas mal de fonctions / mots spécifiques comme reverse_iterator, find_if, ... qui apporte de la sémantique au code.
Par rapport a du code non STL, c'est un peu selon moi la meme comparaison qu'entre un if...then...else et la meme chose avec des goto.
La premiere fois qur tu vois ca, bind1st, find_if, reverse_iterator, t'es pas content, car ca te fait perdre du temps, ca t'oblige a lire la doc et a passer + de temps sur le code que s'il etait ecrit en C.
Mais ... c'est du temps bien investi, au meme titre qu'on perd du temps a maitriser if...then...else et les autres au proffit du GOTO.
Au debut ca gonfle, mais une fois maitrisé, ca glisse tout seul ...

 
je suis d'accord avec tous tes arguments, sauf pour la lisibilité. La boucle en c n'est pas polluée par trois tonnes de trucs. Qu'est qui compte dans la version c++ ? "reverse_iterator", "find_if", "not_equal", tous le reste ne fait que rendre la lecture plus difficile. c'est sans doute une question d'habitude à l'une ou l'autre forme.