Reprise du message précédent :

 
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.

 

 
 
je ne me hasarderais pas a qualifier ce bout de code de 'lisible'

Finalement, il est très bien mon topic. Dire qu'au début, je me suis fais rouler dans la boue, traiter de sale trolleur par certains Admin. Ha là là...

antp est pas admin hein

 
y'a chipotage, la

 
Ouais, ouais, modérateur.
Mais j'parlais pas d'antp de toute façon. Encore moins de gilou...
 
EDIT :  

tu reconnaitras qd meme qu'au début, ton topic partait méchamment en flèche... je ne t'ai pas reproché le sujet du topic, mais le fait que tu dises que la STL était pourrie sans avancer le moindre argument. même si j'avais pas été modo, je te l'aurais signalé. la moindre des choses quand on lance un débat contradictoire, est d'apporter des arguments solides pour argumenter son opinion, ce qui n'a pas été ton cas.
 
l'incident est clos de toute façon. y'a assez de VRAIS boolays comme ça, inutile d'en rajouter. je ne t'ai jamais considéré comme un boolay de toute façon.

Sauf que l'expérience montre que l'une des formes est beaucoup plus sujette aux bugs divers et variés.
Alors certes, je suis d'accord, ce n'est qu'un risque statistique. Mais autant sur 2 ou 3 lignes de code, ça ne veut rien dire, autant à partir de 50 000 lignes de code, ça commence déjà à se faire sentir (et 50 000 lignes de code, ce n'est pas si gros que cela pour un logiciel), et autour de 300 000 ou 500 000 lignes de code, la différence devient énorme, entre un programme jugé très instable par les utilisateurs, ou un programme loué pour sa fiabilité...

<n00b mode : on>
c koi ca :
 
"Et tes objets templates sont-ils arkifies (dont les champs sont accessibles par des metafields) et facilement serialisables?
"
paske la je comprends pas le truc ??
explicazion  svp
<n00b mode : off>
 
Sinon perso, j'utilise la STL au boulot 7/7 24/24 et j'ai jamais eu à m'en plaindre ...

Je mecontente de 39 heures (je suis dans un principauté du sud de la France qui ne connait pas (encore ?) les 35 heures).
 
Si t'as pas célibataire, je plains ta copine qui ne demande qu'un moment d'intimité sans STL.
 
Bon, je sors.

 
C'est ta map de pair de deque et de basic_string ou moi !
 
Non, je sors pas j'ai encore une remarque a faire.
 
LeGreg

 
LOL    
non jdiconne, c une expression (35h pr moi aussi)

 
[OFF TOPIC]
desole c'etait effectivement pas tres clair.
 
Arkifier c'est a dire enregistrer son meta objet aupres du noyau.
(un objet arkifie a donc un meta-objet associe et connu du noyau)
 
Chaque objet possede un meta objet qui decrit ses champs (des meta-champ)et son type (et celui de ses champs).
 
L'importance du meta-objet c'est que le noyau peut creer un objet de sa classe sans avoir besoin de plus d'informations ce qui peut être intéressant pour la sérialisation. Il permet également d'accéder aux valeurs des champs par leur nom sans passer par le mécanisme du C++. Et rien n'empeche de créer des champs a la volée qui n'existent pas dans l'objet C++.
 
Je disais juste ca parce que ce n'etait pas evident de plaquer ce modele sur les collections de la STL.
[/OFF TOPIC]
 
LeGreg

... en clair un peu comme le principe du invokeMethod du Java ?
En pratique ca se fait comment ? Ca m'interrese a donf

Y'a ça ? c'est génial, il manque plus que la méthode messageNotUndestood et on va pouvoir faire des proxys sans se faire chier en java !

 
Euh invokeMethod java?
 
non je ne pense pas.
 
Si c'est comme je le pense juste une méthode de dispatch de methode alors ca n'a pas grand chose a voir.
 
Pour ce qui est du meta objet ca recoupe plusieurs notions, le RTTI (type au runtime) qui permet notamment des dynamic cast (sans utiliser celui du C++) ainsi qu'un objet de description de classe destinee á la sérialisation, impression depuis un module central qui ne sait rien d'autre des objets et des classes qu'il manipule.
 
Ceci dit cette architecture n'est pas de moi alors pas la peine de me poser des questions trop précises.
 
LeGreg

N'est-ce pas là le principe de la réflexion (en Java, classes Class, Attribute, etc) ? A ceci près qu'en Java, en plus, ces classes sont publiques donc utilisables comme n'importe quelle autre objet.

C'est evidemment une reflexion de classes et certains
concepts ressemblent.
Il y a quelques nuances avec java cependant..
 
LeGreg

Lesquelles ?

si tu veux évaluer notre produit je peux
te rediriger vers les personnes compétentes
 
Ceci dit je pense qu'on s'est beaucoup eloigne du sujet original
et que l'on devrait en rester là (ou alors en privé..)
 
LeGreg

up

Avec l'arrivée de NET, j'eviterais l'un et l'autre. De toute facon, pour faire du code windows, actuellement (pas sur un vieux projet a maintenir/ameliorer, mais sur un truc partant de zero), C# me semble etre la meilleure voie.
A+,

On est largement d'accord sur ce point. IMHO, le principal pb a l'utilisation de smalltalk en prod, c'etait la notion d'image du systeme smalltalk.
A+,

Tiens, Gilou, au cas où tu ne l'aurais pas vu les posts auxquels tu réponds ont plus d'un an
 

 
T'as pas honte ?

Ben non, pas quand le topic merite d'etre relancé vu qu'il est interessant.
Justement, apres un an de reflexion, les positions sur STL sont elles toujours les memes??
A+,

 
les templates sont compilés, alors que de partir sur un classe de base CObject amene plus de travail a l'exécution me semble-t-il ?

amène beaucoup plus de travail

 
Je ne vois pas ce qui permet d'arriver à cette conclusion. Archi fausse selon moi.

 
Il y a une librairie nommée WTL (Windows Template Library), pas vraiment officielle, mais qui remplace en grande partie les fnctionnalités des MFC, je crois. L'avantage est une plus grande simplicité et surtout un exécutable semble-t'il bcp plus compact et au moins aussi performant qu'avec les MFC.
Nikos Botzinnis, l'auteur de l'excellent file manager gratuit 2xExplorer , la recommande chaudement sur son site. 2xExplorer est entièrement développé avec la WTL donne une bonne idée des possibilités de la librairie.
 
http://www.rpi.edu/~pudeyo/articles/wtlstart.html
 
Une comparaison avec les MFC ici :
http://www.endurasoft.com/vcd/mfcwtl.htm
 
Une doc WTL (Microsoft ne la documente pas):  
http://www.codeproject.com/wtl/
http://codeworks.gnomedia.com/wtl/index.php

 
Absolument, et c'est là, je trouve, que la syntaxe du C++ montre ses limites.  
Les deux versions du programme, C et STL, sont à peu près aussi illisibles l'un que l'autre (aux réserves mentionnées plus haut près).
L'exemple donné montre que la syntaxe du C++ devient un handicap lorsqu'on veut se mettre à faire des choses qui s'expriment beaucoup plus simplement et naturellement dans des langages fonctionnels.

Histoire de relancer ce topic.
 
La stl, je trouve ça très bien à quelques petites réserves près.
 
D'abord, je n'aime pas les confusions du type "stl = C++" et les niaiseries du type "si un code n'est pas gavé d'appels à la stl alors ce code n'est du pas C++". Ensuite, les implémentations de la stl sont souvent efficientes mais amènent quand même des petites pertes par rapport à un code C++ parfaitement "designé" pour ses besoins.
 
Le plus gros reproche que j'ai à faire n'est pas tant à la stl qu'aux programmeurs qui l'utilisent. De ce que j'ai pu voir récemment, beaucoup ne savent pas ce que leur code fait réellement. Ce que je veux dire par là, c'est qu'ils n'ont visiblement qu'une très vague idée des mécanismes mis en jeu par leur code. Lorsqu'on a déjà écrit des outils pour faire, grosso-merdo, ce que fait la stl, à terme, on n'a plus ce problème. C'est-à-dire qu'un programmeur débutant écrira bien naturellement des horreurs mais au fur et à mesure qu'il progressera, qu'il cherchera à comprendre comment optimiser son code et qu'il descendra de plus en plus bas pour ce faire, il finira par mieux comprendre son code que le type qui s'est contenté d'utiliser la stl toute sa vie. Ce fastidieux et long travail peut sembler totalement inutile à certains mais sur ce point, je rejoins wave: un programmeur ayant de gros besoins en performances doit parfaitement connaître tout ce qu'implique son code et ce n'est pas en se contentant d'utiliser la stl qu'on apprend ce genre de choses.

Pourquoi ai-je comme l'impression que quelqu'un est visé?
 

Tout a fait d'accord, mais il n'a jamais été question de l'intéret pédagogique de la STL.
Lorsqu'on veut apprendre, il faut réinventer la roue (si y'a bien quelque chose qui me fait pitié c'est les soi-disant "programmeurs" PHP qui cherchent désespérement la fonction toute faite qui fera le boulot a leur place, alors qu'ils auraient tout a gagner a tenter de la programmer eux meme!)
Lorsqu'on programme, tant que faire se peut, non!

c'est une erreur de ta part, puisqu'une grosse partie de la stl est passée dans la norme C++ actuelle qui date quand même de plusieurs années

Et alors? Ca veut dire que la STL fait partie du C++, mais ca veut pas dire qu'on est obligés de l'utiliser!

C'est vrai, mais le problème se pose pour la STL comme pour toutes les librairies : doit-on développer tout soi-même, afin de garder un contrôle total sur le code, ou doit-on utiliser des librairies, dont on sait "qu'en moyenne", elles réalisent de nombreuses choses mieux que soi, sauf à y passer un temps prohibitif ? En production, bien souvent, la question ne se pose pas : vu le coût du développement, on préfère acheter des "components off the shelf" plutôt que de réinventer la roue pour la énième fois. Il ne viendrait à (presque) personne l'idéee de réécrire OpenGL par exemple, parce qu'il est peu probable qu'on fasse bcp mieux, même avec bcp d'efforts. Quand un projet fait des centaines de milliers de lignes, bien souvent, on ne cherche pas à tout optimiser manuellement, on cherche à utiliser au mieux l'existant, dans les contraintes qui sont imposées. Or faire bcp mieux que la STL demande un certain effort d'otimisation. Une autre raison d'utiliser des librairies, est que ça unifie et robustifie le code : il n'y aura pas 3 vesions de quicksort, 5 structures de tables de hachage dont 3 complètement buggées, etc. Bref, le besoin est évident et ce n'est pas le fait du hasard si la librairie fait partie du standard. Je considère comme d'autres que la STL est partie intégrante du langage.
Malheureusement, dans l'enseignement du C++, bien trop souvent, cet aspect est négligé, et c'est à mon sens une erreur grossière. Si la STL faisait partie de l'enseignement, les programmeurs sauraient certainement bcp mieux ce qu'elle fait, et comment elle fonctionne. Le fait est que très peu de programmeurs connaissent bien cette librairie. Dans un projet pour lequel j'ai travaillé récemment, un programmeur expérimenté me disait que s'il avait étudié les différents conteneurs de la STL plus tôt, il aurait tout implémenté différemment. Alors à mon avis, ce n'est pas la panacée (loin de là), mais cela devrait faire partie du bagage de tout programmeur C++.

ben ouais mais bon, dès que tu fais 'cout' t'y es

"etudié les différent conteneurs ... " tu veux dire leur fonctionnement externe ou interne?

 
si peu
 

 
Ah putain que ça fait du bien de lire ça!
 

 
Et ça aussi!
 
J'ai souvent l'impression de parler à des psycho-rigides incapables de prendre en compte la complexité d'un contexte donné pour se réfugier au final derrière des pseudo-principes à trois francs six sous (exemple type: les macros, tu peux pas les débugguer => sapuduku et il faut jamais les utiliser).
 
 
el muchacho> tout à fait d'accord

 
Je veux dire, au minimum, étudier leurs interfaces et la complexité des algos (qui est spécifiée), afin de savoir les utiliser au mieux pour chaque application.