Discussion :

[Issam_Lahlali]

Le principe c'est quand même que Qt fournira le nécessaire pour ne pas avoir à se prendre la tête côté C++ !

Donc tu t'en fous simplement de bien orthographier ?
Le manque de respect envers Qt et son équipe, ça ne te dérange pas ?

tu trouve normal la non adoption de XML Autant ne pas utiliser le standard STL alors, les standards sont fait pour converger et pour limiter les complexités.

et j'en suis sur et certain que si QT avait adopté un format XML personne ne se plainera , au contraire on va venter le fait qu'ils ont utiliser un standard et leurs choix sont très bien fait comme d'habitude.

et pour QT je ne sait pas si un T en majuscule va changer quoi que soit dans mon respect ou non a Qt , d'ailleurs j'ai plusieurs fois dis que QT c'est très bien et MFC c'est du n'importe quoi, et comme je l'est déjà dis c'est une question forme.

[yan]

J'espère que cela est une blague parce que ton code moderne c'est comme cela que j'écrivais il y a 10 ans...

Ben la dernier version du C++ date de?
Et depuis, beaucoup de prof n'as pas passé le cap et donc les élèves
En plus si tu veut faire du c++ moderne,
tu aurais plutôt fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct MyGenerate
{
    int count = 0;
    MyGenerate() {count = 0;}
    int operator(){ return count++; }
};
 
 
std::vector<int> v(5);
std::generate( v.begin(), v.end(), MyGenerate() );

Et dans la prochaine norme, tu pourra écrire ton foncteur directement dans le generate.

Pour ce qui est de Qml vs xaml, je pense que c'est un tout autre débat : le développement d'IHM.
Je ne sais pas si tu as fait beaucoup d'IHM, mais c'est vraiment un truc chiant et fastidieux. Plein de ligne pour pas grand chose en faite
Qt fait aussi du xml (.ui) Mais faut toujours faire encore d'autre ligne de code pour l'exploiter.

Tu peut constater dans tous les language (xaml, qml,...), tous le monde essaie de simplifier ce type de développement d'une manière ou d'une autre.
Chaque solution avec sont avantage et ses inconvénients. Par exemples
xaml : xml, mais il te faut un ide graphique pour l'exploiter correctement car difficile à lire et éditer à la main.
qml : un éditeur de texte. D'ailleurs, si tu regarde bien, c'est plutôt du xml déguisé. C'est très structuré.

[Matthieu Brucher]

en aucun cas il ne faut prendre en compte l'ordre des balises , si on a un ordre a prendre en compte c'est coté métier qu'il faut le faire donc a travers des attributs donc jamais l'ordre n'a de sens excepté si on veut faire du couplage fort.

Et il aura sans doute raison. C'est ce que je fais à un moment pour un outil de calcul distribué pour gérer qui va faire quoi. Et il n'y a pas de couplage fort à ce niveau. Un attribut dans une balise, vraiment très couplé !

et c'est vrai que je mélange Metier et technique mais cette erreur de conception est le meilleur exemple de mélange de Metier et technique .

Quelle conception ?

pour être clair imaginant qu'on vous demande de faire un stockage en base de données aussi en plus du stockage xml et vous vous êtes baser sur l'ordre des balises en xml comment vous allez gérer cet ordre , vous aller prendre en compte l'ordre d'insertion dans la table?

Mauvais exemple, il n'y a pas d'ordre dans ce cas si on fournit toutes les informations dont les clés.

et a plusieurs reprises on m'accuse d'inexpérience en sortant des mécanismes soit disant avancés mais est ce qu'au moins on maitrise ce qui est basique a savoir le Couplage Faible.

Si ça, ce n'est pas une attaque personnelle...

et c'est l'erreur récurrente que j'ai rencontrer dans différents projets qu'on néglige souvent.

Oui, tu as sans doute raison, mais ça n'a rien à voir avec ce que je te dis. Tu veux imposer tes vues alors que tu ne connais pas vraiment le sujet (les différents types de polymorphisme, ...)

et revenant a XML , a plusieurs reprises les intervenants ne comprennent pas pourquoi il ya un standard STL qu'on néglige mais est ce normal qu'il ya un autre standard XML qu'on néglige aussi?

Aucun rapport, XML est un langage, QML en est aussi un. Dans ce cas, pourquoi est-ce qu'on a un standard Fortran, un standard C, un standard Python, ... alors qu'ona un standard C++ ?

et enfin voici quelqu'un d'inexpérimenté va dire de XML :

a un moment j'ai participer au développement d'un outil de migration de C++ a Dotnet , et ce qui nous a faciliter la tache était justement XML , en fait a partir des headers on récupèrent des fichiers xml qui décrivent les classes et on utilise les parseurs XML pour récupérer ce qu'il nous fallait et c'était trop bénéfique.

imaginant que c'est pas XML et c'est un autre format il fallait déjà développer un parseur de ce format avant d'aller trop loin, et je te dis pas la complexité du projet après.

Ai-je dis le contraire ? J'utilise XML aussi pour exactement la même chose (cf mon blog avec gccxml).

si QT ( qui n'est pas quick time bien sur ) décide d'adopter un format spécifique , c'est pas le fait que je suis adepte de QT que j'accepterais tous ce qu'elle propose , mais peut être si j'étais actionnaire je changerais d'avis

et un dernier conseil aux débutant ne soyer jamais intimider par des arguments genre manque d'expérience ou autre, rester toujours objective et critiquer ce qui vous parait compliquer et fait des réflexions avant d'adopter ce qu'on vous donnent.

Est-ce que j'ai dit que ce que faisait Qt faisait acte de loi ?

concerant QML pour toi tu ne touche pas QML mais d'autres qui veulent faire du MDA forcement ils vont les toucher, et justement puisqu'on ne va jamais les toucher pourquoi finalement c'est pas du XML.

Parce que ça ne répondait pas à leur problématique ! D'ailleurs, pourquoi ils n'ont pas fait ça en C++ directement ?

pour QT j'ai bien compris mais juste pour montrer que c'est une question de forme non de fond.

C'est une question de respect et de compréhension. En plus tu te fais un hérault de cela, et à la première occasion...

et pour tes derniers questions , j'en ai déjà répondu plusieurs fois, éviter le débat de personne avec des phrases genre tu connais rien de rien et essayant de débattre l'idée qui est l'adoption de XML ou pas avec des arguments,si tu relis mes derniers posts j'ai donner plusieurs arguments et s'il ne sont convaincantes essaye de proposer tes arguments sans entrer dans un débat entre personnes

Il me semble que ce n'est pas un débat de personne, mais un débat où il est nécessaire de mettre tout sur la table. Or, dans certains cas, il faut renseigner certains intervenants qui n'ont pas toutes les cartes en main. Après, s'ils prennent ces posts INFORMATIFS pour eux, c'est qu'il y a un souci (il faut peut-être se remettre en question ? Ca revient à ce que tu dis sur les débutants dans le post précédent qui implique que certains doivent bien se remettre en question).

et pour arrêter ces attaques de personnes ,j'avoue que je suis nul et je ne connais rien , considérer moi comme un débutant qui découvre le langage et essaye de critiquer les complexités induites par le manque de conception en restant toujours dans un débat d'idées.

C'est bien pour a que je te donne des éléments complémentaires.

J'espère que cela est une blague parce que ton code moderne c'est comme cela que j'écrivais il y a 10 ans...

Mon intuition ne me trompe pas complètement, c'est quand même une grosse part de vent et marketing pour ressuscité le langage

Oui, on pouvait/devait déjà programmer comme ça à l'époque ! Et oui, c'est une honte de devoir ressortir ça comme ça parce que les développeurs de l'époque n'ont pas pris le temps de se remettre à jour (et ça se voit dans les évolutions des autres langages, comme C99, même Fortran 90, ...)

C++ moderne Désolé mais c'est que du vent marketing pour vendre de nouveaux concepts et fonctionnalités.

Mais donne-nous un exemple d'équivalence de code moderne et de code moyen âgeux pour bien sentir la différence mais cela va tellement resté dans le technique que se sera peu intéressant..

cf plus haut, ce n'est pas de nouveaux concepts, comme tu le dis

tu trouve normal la non adoption de XML Autant ne pas utiliser le standard STL alors, les standards sont fait pour converger et pour limiter les complexités.

La STL fait partie du standard C++. Le langage XML non. Et pourtant, ils utilisent XML pour énormément de chose, c'est donc qu'il y a un point qui ne leur convient pas.

et pour QT je ne sait pas si un T en majuscule va changer quoi que soit dans mon respect ou non a Qt , d'ailleurs j'ai plusieurs fois dis que QT c'est très bien et MFC c'est du n'importe quoi, et comme je l'est déjà dis c'est une question forme.

Si, je considère ça comme une attaque, quoiqu'il en soit, tout comme toi tu considères mes posts comme une attaque contre toi.

[Luc Hermitte]

et revenant a XML , a plusieurs reprises les intervenants ne comprennent pas pourquoi il ya un standard STL qu'on néglige mais est ce normal qu'il ya un autre standard XML qu'on néglige aussi?

XML n'est pas fait pour être manipulé par un humain.
S'il était si important, les DTD seraient décrites en XML, les fichiers de propriétés (typiquement avec ant) seraient en XML, Le Java et le C++ seraient en XML, et YAML et JSON n'auraient pas vu le jour.

C'est un format gentil, mais pas adapté à certaines problématiques -- grosses volumétries, et autres échanges temps-réels, édition par humain.
Quant aux parseurs XML ... mais quelle catastrophe. DOM comme SAX c'est lourdingue au possible. Et en C++, au passage nous avons droit à certains parseurs à l'API moyenâgeuse (cf Xerces-C).

Passons sur XSLT qui est rigolo, mais je préfère le Prolog (j'aime beaucoup le Prolog en fait), et docbook au combien immature comparé à LaTeX (puisque l'on parle de standards établis) (je pense en particulier au projet docbook-xsl qui est la grosse référence pour monsieur tout le monde qui veut faire du docbook).

Bref. Pour moi XML est un gros pipo commercial qui a pris et que j'aimerai bien comprendre pourquoi j'avoue. Parce que lex&Yacc étaient trop compliqués ? Il a ses utilités, mais comme le downcasting, l'héritage public, les mutateurs, les mutex, les singletons, ... il faut savoir reconnaitre les cas où il n'est pas bien venu.

Comment on en est venus à XML encore ?

Le "C++ moderne" est un terme un peu pompeux, je suis d'accord.
En gros, c'est ce qui découle du bouquin de Andrei Alexandrescu, Modern C++ design,

Ce n'est pas la définition que j'en ai. J'oppose moderne à historique. Et historique, c'est le C/C++ non error-safe. L'error-safety est bien plus importante que la meta-prog. Et si en plus on peut l'atteindre de façon simple et maintenable, bingo. Quand l'historique cessera de dominer, le C++ correct sera peut-être moins moderne et la méta-prog autre chose que de la SF.
Le C++ meta-prog est d'un maigre intérêt pour le développeur C++ en fin de circuit, celui dont le métier n'est pas l'informatique, mais le spatial, l'automobile, le traitement de texte, ... Elle est en revanche plus utile pour définir des bibliothèques génériques, cf boost.

[gl]

[HS]

et pour QT je ne sait pas si un T en majuscule va changer quoi que soit dans mon respect ou non a Qt , d'ailleurs j'ai plusieurs fois dis que QT c'est très bien et MFC c'est du n'importe quoi, et comme je l'est déjà dis c'est une question forme.

C'est peut être une question de forme, mais ça n'en reste pas moins important. Pour pouvoir communiquer, il faut au minimum un vocabulaire commun, si tu ne respecte pas ce vocabulaire, il est difficile de se faire comprendre.

Lorsque je lis QT je pense plus QuickTime que Qt et du coup la discussion n'est plus intelligible.

A ce compte là, pourquoi ne pas utiliser "cvgbndfbvjdbj" à la place de "conception" et "rzrrezrezr" pour "développement" ? après tout ce n'est qu'une question de forme donc sans importance si on suit ton raisonnement.
[/HS]

[nikko34]

Le C++ meta-prog est d'un maigre intérêt pour le développeur C++ en fin de circuit, celui dont le métier n'est pas l'informatique, mais le spatial, l'automobile, le traitement de texte, ... Elle est en revanche plus utile pour définir des bibliothèques génériques, cf boost.

exactement!

Et dans une équipe, il peut y avoir quelqu'un de calé en métaprog et autres qui fait des bibliothèques dans le seul intérêt de simplifier la vie aux autres développeurs.

C'est pour cette raison que je trouvais dommage les tutoriaux boost sur developpez.com qui commençaient par une explication technique de la bibliothèque alors que ce qui est important est son utilisation. La bibliothèque est compliquée mais c'est ce qui fait que son utilisation est simple.

[Alp]

Et dans une équipe, il peut y avoir quelqu'un de calé en métaprog et autres qui fait des bibliothèques dans le seul intérêt de simplifier la vie aux autres développeurs.

Je dirais même que c'est une très bonne approche ! Enfin, il ne faut pas pour autant que les autres développeurs ignorent tout des templates.

Sinon, +1 à Luc, Matthieu et les autres sur tout.

[metagoto]

A propos de :

Le "C++ moderne" est un terme un peu pompeux, je suis d'accord.
En gros, c'est ce qui découle du bouquin de Andrei Alexandrescu, Modern C++ design

Ce n'est pas la définition que j'en ai. J'oppose moderne à historique. Et historique, c'est le C/C++ non error-safe. L'error-safety est bien plus importante que la meta-prog. Et si en plus on peut l'atteindre de façon simple et maintenable, bingo. Quand l'historique cessera de dominer, le C++ correct sera peut-être moins moderne et la méta-prog autre chose que de la SF.
Le C++ meta-prog est d'un maigre intérêt pour le développeur C++ en fin de circuit, celui dont le métier n'est pas l'informatique, mais le spatial, l'automobile, le traitement de texte, ... Elle est en revanche plus utile pour définir des bibliothèques génériques, cf boost.

Alexandrescu ne prone pas la meta prog en tant que fin en soi. Il s'efforce de mettre en avant la possibilité de contraindre le plus possible le design des applications par le système de typage, dans le but premier de réduire les erreurs. Asservir un maximum de choses à la compilation. C'est du C++ moderne ? Je pense que oui!

[Issam_Lahlali]

Mauvais exemple, il n'y a pas d'ordre dans ce cas si on fournit toutes les informations dont les clés.

Oui, tu as sans doute raison, mais ça n'a rien à voir avec ce que je te dis. Tu veux imposer tes vues alors que tu ne connais pas vraiment le sujet (les différents types de polymorphisme, ...)

justement et c'est de la même manière qu'il faut mettre les infos dans les attributs , et c'est pour cela que je parle de couplage fort , parce que si on se souci de l'ordre des balises pour XML c'est du couplage fort avec XML et ça ne va pas marcher avec les bases de données excepté si on repense la logique.

Oui, tu as sans doute raison, mais ça n'a rien à voir avec ce que je te dis. Tu veux imposer tes vues alors que tu ne connais pas vraiment le sujet (les différents types de polymorphisme, ...)

est ce que défendre une idée implique imposer son idée , alors dans ce cas on doit tous penser de la même manière , et finalement on aura un seul langage , et surtout dans ce domaine informatique personne n'a le savoir absolu, c'est pour cela que heureusement il y a des discussions comme ça.

Aucun rapport, XML est un langage, QML en est aussi un. Dans ce cas, pourquoi est-ce qu'on a un standard Fortran, un standard C, un standard Python, ... alors qu'ona un standard C++ ?


La STL fait partie du standard C++. Le langage XML non. Et pourtant, ils utilisent XML pour énormément de chose, c'est donc qu'il y a un point qui ne leur convient pas.

et pour XML pourquoi on le considère dans un monde et C++ dans un autre monde, ils font parti tout les deux du même monde qui est celui du développement et va demander aux gens d'EAI c'est quoi leur bête noire, ils vont te répondre le nombre incalculable de format specifiques.

il ne faut pas rester piéger dans son monde C++ il y a l'EAI, MDA et autre qui sont facilité par l'utilisation de XML , il m'est arriver de travailler dans des projets EAI ou j'aimais que les représentations soit en XML mais hélas tout ce que complique du a l'existence de plusieurs format spécifique et va développer un parseur pour chaque format.

c'est vrai si je pense juste a mes projets qui ne représentent même pas 0.1% des types possible de projets , je dirais c'est pas grave xml ou pas ça ne changera pas beaucoup, mais dans la réalité il ya énormément de projets possibles et d'ailleurs ceux sur lesquels j'ai bosser il n y avait pas que C++ mais d'autres langages et techno et plusieurs problématiques était régler facilement grâce a XML.

et pour le polymorphisme statique ou dynamique qu'on me demande a chaque fois , j'ai lu vos livres de références et j'ai pris du temps d'essayer de résoudre tous les problèmes du site http://www.gotw.ca/gotw/ et voici une autre bonne référence http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms.

et la question que je me pose a chaque fois est la suivante: est ce que si les quelques personnes qui ont contribuer a faire connaitre le C++ moderne n'existaient pas est ce que ces concepts existeront? après réflexion eux ils ont arriver a ce résultat extraordinaire dans un souci de simplifier les choses donc il faut apprendre aussi çà et suivre aussi leur démarche au lieu de suivre juste leurs résultats.


et pour Qt mes respects a Qt et a l'équipe de Qt et tout ceux qui utilisent Qt, on me va pas avoir énormément de post juste me faire comprendre qu'il faut respecter Qt.

[JolyLoic]

il ne faut pas rester piéger dans son monde C++ il y a l'EAI, MDA et autre qui sont facilité par l'utilisation de XML , il m'est arriver de travailler dans des projets EAI ou j'aimais que les représentations soit en XML mais hélas tout ce que complique du a l'existence de plusieurs format spécifique et va développer un parseur pour chaque format.

Le problème d'XML, c'est qu'il faut quand même développer un parseur derrière. Ce parseur ne parlera pas en teme de caractères ou de regexp, mais en terme de noeuds et de XPath, mais le travail à faire est considérable (peut-être à cause des manques de bonne bibliothèques de parsing XML ?).

En gros, pour moi, un fichier peut être de 4 types :
- Avec de fortes contraintes de performances/compression : Binaire
- Fait pour être lu/écrit par un humain, et dans ce cas XML est bien trop verbeux, lourd et illisible. C'est le domaine des parseurs fait main, lex/yacc antlr, spirit...
- Fait pour être lu par un programme pour sérialiser ses données, et dans ce cas, il y a des bibliothèques qui permettent de ne pas se préocuper de format de sauvegarde, juste de décrire ce qu'on veut sauver, et qui diminuent énormément le travail d'écriture de code, ainsi que les risques de bug. C'est le domaine de libs comme boost::serialization.
- Fait pour servir de format d'échange entre programmes. C'est là seulement que je vois un intérêt à XML, même si j'aurais préféré qu'il soit moins tordu.

[Issam_Lahlali]

Le problème d'XML, c'est qu'il faut quand même développer un parseur derrière. Ce parseur ne parlera pas en teme de caractères ou de regexp, mais en terme de noeuds et de XPath, mais le travail à faire est considérable (peut-être à cause des manques de bonne bibliothèques de parsing XML ?).

En gros, pour moi, un fichier peut être de 4 types :
- Avec de fortes contraintes de performances/compression : Binaire
- Fait pour être lu/écrit par un humain, et dans ce cas XML est bien trop verbeux, lourd et illisible. C'est le domaine des parseurs fait main, lex/yacc antlr, spirit...
- Fait pour être lu par un programme pour sérialiser ses données, et dans ce cas, il y a des bibliothèques qui permettent de ne pas se préocuper de format de sauvegarde, juste de décrire ce qu'on veut sauver, et qui diminuent énormément le travail d'écriture de code, ainsi que les risques de bug. C'est le domaine de libs comme boost::serialization.
- Fait pour servir de format d'échange entre programmes. C'est là seulement que je vois un intérêt à XML, même si j'aurais préféré qu'il soit moins tordu.

Merci infiniment LOIC voila ce que j'appelle une argumentation précise.

en fait pour le parsing j'utilise aussi du SAX sans utiliser du XPath ou des noeuds.

et comme t'a mentionner pour echange entre programme l'idéal est XML avec des reserves et on a ce cas de plus en plus vu le nombre croissant de techno cohabitant dans un même projet.

et pour ceux qui doivent être écrit et lu par un être humain , dans tout les cas je considère que c'est mieux de passer par un outil qui fait abstraction a la complexité et surtout le rôle de l'outil et d'encadrer les changements pour éviter les erreurs qu'on fait en général lorsqu'on touche le fichier manuellement.

a ma connaissance a chaque fois qu'on laisse accessible un fichier manuellement on a tendance a faire des erreurs,prenant l'exemple des fichiers de configurations on galère pas mal si on les changent manuellement ou a chaque fois il faut trouver ou est l'erreur par contre si c'est encadré par un outil il va limiter l'utilisateur juste a ce qui est possible et tout le monde gagnera du temps.

et pour le binaire tout a fait raison , il ya des cas ou le binaire est le plus adapté.

[koala01]

a ma connaissance a chaque fois qu'on laisse accessible un fichier manuellement on a tendance a faire des erreurs,prenant l'exemple des fichiers de configurations on galère pas mal si on les changent manuellement ou a chaque fois il faut trouver ou est l'erreur par contre si c'est encadré par un outil il va limiter l'utilisateur juste a ce qui est possible et tout le monde gagnera du temps.

Le problème est que tout fichier est, par nature, accessible aux gens ou à des outils qui n'ont pas été prévus en vue de le gérer "efficacement" (comprend: en évitant les incohérences et les manipulations hasardeuses)...

Quand j'écris une page internet, cela ne me prend presque pas plus longtemps et j'ai de meilleurs résultats d'écrire toutes les balises à la main que de garder ce que les outils "prévus pour" et WYSIWYG peuvent produire (et que je devrai de toutes manière vérifier et corriger)...

Le fait de modifier à la main le fichier de config de certains jeux permet souvent d'avoir de meilleurs rendu, des scènes plus fluides ou un niveau de détail bien meilleur que ce que tu peux obtenir en utilisant uniquement l'interface prévue à cet effet

De nombreuses applications pourant fenêtrées sont utilisables directement en ligne de commandes et proposent des options qui sont indisponibles depuis l'IHM fenêtrée

Et la liste d'exemple pourrait continuer ainsi pendant longtemps.


Tout cela pour te dire que les raisons qui t'incitent à ne pas utiliser *systématiquement* l'outil "prévu pour" sont légions et que tu trouvera un grand nombre "d'abrutis" qui décideront d'aller tripatouiller eux même dans les différents types de fichiers...

Même s'il est vrai que le risque de faire des erreurs est particulièrement important dans ce cas.

Dés lors, il est temps de se rappeler la loi de murphy et de se dire que, quoi qu'il arrive, s'il y a un erreur à faire, tu trouvera toujours quelqu'un pour la commettre

Et cela justifie déjà très amplement le fait de ne pas chosir XML pour tout et n'importe quoi

[Invité]

En plus si tu veut faire du c++ moderne,
tu aurais plutôt fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct MyGenerate
{
    int count = 0;
    MyGenerate() {count = 0;}
    int operator(){ return count++; }
};
 
 
std::vector<int> v(5);
std::generate( v.begin(), v.end(), MyGenerate() );

Et dans la prochaine norme, tu pourra écrire ton foncteur directement dans le generate.

Ouais, c'est sur que ce genre de syntaxe va attirer beaucoup de monde au C++ moderne...

Sérieusement, recruter des développeur un peu expérimentés en C++ (et non psychopathes) devient difficile. Est ce réellement en poussant le programme encore plus dans le sens de l'abstraction gratuite qu'on va arranger les choses? (oui parce que sérieusement, si planquer le new dans un vecteur et espérer que le compilateur va bien optimiser size, c'est un peu cosmétique, mettre un foncteur dans ce cas précis, là où, soit dit en passant, un appel à iota() suffirait, ça relève de l'obfuscation)

En gros, la boucle de départ, avec son new, n'ira probablement pas moins vite, elle ne présente aucun danger, et n'importe qui (même quelqu'un qui ne connait pas le C++) pourra la lire et la comprendre. Le foncteur, j'en doute, ne serait ce parce que le code de cette boucle très simple est maintenant coupé en deux.

Je ne peux m'empêcher d'y voir une forme d'autosatisfaction intellectuelle... Le programmeur va peut être s'économiser une demi ligne de code s'il réutilise son foncteur trois fois, mais celui qui devra passer derrière va passer un sale moment, avec un code aussi éclaté.

Il y a bien sur des cas où les foncteurs servent, mais cet exemple ne me parait pas servir le langage...

Francois

[Issam_Lahlali]

Le problème est que tout fichier est, par nature, accessible aux gens ou à des outils qui n'ont pas été prévus en vue de le gérer "efficacement" (comprend: en évitant les incohérences et les manipulations hasardeuses)...

Et cela justifie déjà très amplement le fait de ne pas chosir XML pour tout et n'importe quoi

ton raisonnement est correcte mais il y a des cas ou le mieux est de ne pas toucher a la main , est dans notre cas comme l'a bien préciser Alp que jamais il ne touchera le QML a la main et Qt a prévu des outils pour, on peut faire alors du XML ca facilitera l'intégration avec d'autres technos.

je suis d'accord qu'il ne faut pas utiliser XML pour tout et n'importe quoi , mais pour ce cas precis de QML j'aurais aimer avoir du XML mais finalement c'est un choix personel ou j'ai donner mes arguments et c'est pas ca qui va convaincre Qt.


et sincèrement j'aurais bien aimer découvrir l'avis des adeptes de Qt si Qt avait choisit XML, je ne peux que deviner qu'ils vont le venter en sortant énormément d'arguments .

je pars d'un principe:aucun système n'est idéal a 100% et adopter une librairie ne veut pas dire être tout le temps d'accord avec leurs choix, et j'ai l'impression qu'actuellement on a des clans (C++,Java,Perl,Windows,Unix,...) et on le voient dans les troll interminables .

je suis pour le choix qui me parait bien dans un contexte donné , au moins j'essaye , ca m'est deja arriver de conseiller unix pour certain projets et windows pour d'autres et aussi c++,vb,dotnet,perl,java et autre langages en depend du contexte.

et dans cet optique d'utiliser plusieurs langages et technos que je suis pour l'utilisation de XML ça me facilite beaucoup l'architecture et la conception.

alors finalement on ne peut juger un choix qu'a l'intérieur du contexte dans lequel on travaille, et c'est pour cela qu'il nya pas une solution idéale quelque soit le cas.

et si on utilise que C++ je comprends que XML ou pas ça change rien.

mais de mon coté je ne pense pas qu'a C++ mais a tout langage et techno capable de résoudre une problématique d'une manière simple et pour une application donnée je peux avoir plusieurs langages et technos utilisés.

peut etre je suis hors sujet mais c'était obligatoire pour expliquer pourquoi dans ma façon de faire les choses je m'accroche a XML mais finalement chacun a ces choix qui lui parait bénéfique pour son contexte et ses projets.

[Matthieu Brucher]

est ce que défendre une idée implique imposer son idée , alors dans ce cas on doit tous penser de la même manière , et finalement on aura un seul langage , et surtout dans ce domaine informatique personne n'a le savoir absolu, c'est pour cela que heureusement il y a des discussions comme ça.

...
Il va falloir se décider : soit tu imposes XML, soit tu ne l'imposes pas. Tu ne peux pas penser une chose et son contraire.

[Matthieu Brucher]

et sincèrement j'aurais bien aimer découvrir l'avis des adeptes de Qt si Qt avait choisit XML, je ne peux que deviner qu'ils vont le venter en sortant énormément d'arguments .

Aucun rapport, ils le font déjà.

je pars d'un principe:aucun système n'est idéal a 100% et adopter une librairie ne veut pas dire être tout le temps d'accord avec leurs choix, et j'ai l'impression qu'actuellement on a des clans (C++,Java,Perl,Windows,Unix,...) et on le voient dans les troll interminables .

Tiens, ça ressemble à ce que tu fais quand tu parles d'XML... Qui d'ailleurs n'a rien à voir avec le fait que les développeurs C++ font attention à la conception ou pas !

je suis pour le choix qui me parait bien dans un contexte donné , au moins j'essaye , ca m'est deja arriver de conseiller unix pour certain projets et windows pour d'autres et aussi c++,vb,dotnet,perl,java et autre langages en depend du contexte.

Fais confiance à des gens qui font ça depuis avant que tu sois né !

et dans cet optique d'utiliser plusieurs langages et technos que je suis pour l'utilisation de XML ça me facilite beaucoup l'architecture et la conception.

Aucun rapport. XML peut aider, mais JSON aussi, par exemple.

[Luc Hermitte]

En gros, la boucle de départ, avec son new, n'ira probablement pas moins vite, elle ne présente aucun danger, et n'importe qui (même quelqu'un qui ne connait pas le C++) pourra la lire et la comprendre. Le foncteur, j'en doute, ne serait ce parce que le code de cette boucle très simple est maintenant coupé en deux.

Au contraire, new[] présente un danger.
Si tu as une seconde allocation dans la portée, ou n'importe quoi qui pourrait lever une exception suite à évolution pour maintenance, il faut revoir le code pour éviter la fuite.

vector, c'est potentiellement quelques caractères en plus à taper, une garantie de collecte de la mémoire associée (pour les types non pointeur, sinon il y a un travail supplémentaire à réaliser), et diverses fonctionnalités bonus (expansible, et redimensionable (pas mal dans des boucles, cela permet de faire des pools de mémoire du pauvre)).

Pour generate, je ne dis pas. Je n'ai rien contre le fonctionnel (même la version pauvre, en VimL et en perl, je l'apprécie), faut-il que cela soit simple à utiliser -- et les foncteurs n'aident pas.

---
Pour QML vs XML, pour moi on retrouve une partie du débat de LaTeX vs docbook. QML n'est qu'un DSL de plus, c'est à la mode en ce moment (c'est plus facile à vendre les choix technologiques quand il y a un terme hype derrière, comme MDA, le terme est hype).

[koala01]

ton raisonnement est correcte mais il y a des cas ou le mieux est de <snip>

Tout tient dans ces quelques mots: "le mieux est de"...

Sauf que, par nature (et je ne parle pas forcément que des développeurs, mais bien, plutôt de tous les utilisateurs en générale), l'homme est un imbécile distrait qui choisi finalement assez rarement la "meilleure solution" ou ne serait-ce que la solution correcte

dans notre cas comme l'a bien préciser Alp que jamais il ne touchera le QML a la main et Qt a prévu des outils pour, on peut faire alors du XML ca facilitera l'intégration avec d'autres technos.

je suis d'accord qu'il ne faut pas utiliser XML pour tout et n'importe quoi , mais pour ce cas precis de QML j'aurais aimer avoir du XML mais finalement c'est un choix personel ou j'ai donner mes arguments et c'est pas ca qui va convaincre Qt.


et sincèrement j'aurais bien aimer découvrir l'avis des adeptes de Qt si Qt avait choisit XML, je ne peux que deviner qu'ils vont le venter en sortant énormément d'arguments .

je pars d'un principe:aucun système n'est idéal a 100% et adopter une librairie ne veut pas dire être tout le temps d'accord avec leurs choix, et j'ai l'impression qu'actuellement on a des clans (C++,Java,Perl,Windows,Unix,...) et on le voient dans les troll interminables .

je suis pour le choix qui me parait bien dans un contexte donné , au moins j'essaye , ca m'est deja arriver de conseiller unix pour certain projets et windows pour d'autres et aussi c++,vb,dotnet,perl,java et autre langages en depend du contexte.

et dans cet optique d'utiliser plusieurs langages et technos que je suis pour l'utilisation de XML ça me facilite beaucoup l'architecture et la conception.

alors finalement on ne peut juger un choix qu'a l'intérieur du contexte dans lequel on travaille, et c'est pour cela qu'il nya pas une solution idéale quelque soit le cas.

et si on utilise que C++ je comprends que XML ou pas ça change rien.

mais de mon coté je ne pense pas qu'a C++ mais a tout langage et techno capable de résoudre une problématique d'une manière simple et pour une application donnée je peux avoir plusieurs langages et technos utilisés.

peut etre je suis hors sujet mais c'était obligatoire pour expliquer pourquoi dans ma façon de faire les choses je m'accroche a XML mais finalement chacun a ces choix qui lui parait bénéfique pour son contexte et ses projets.

Je me suis mal exprimé dans le sens où, visiblement, j'ai donné l'impression que je suis totalement contre XML, alors que je voulais surtout présenter le fait que tout fichier humainement compréhensible (avec tout ce que cela comporte) risque d'être "titillé" sans utiliser l'outil le plus adéquat permettant de travailler "sans risque" par une personne.

<troll ... ou presque>Ce sera d'ailleurs souvent par celle qui viendra se plaindre sur un forum que "ca marche pas"
</troll>
Mais, quoi qu'il en soit, le format de fichier utilisé, que ce soit pour permettre la persistance des données, pour fournir des informations de compilation IHM, pour permettre à deux ordinateurs de communiquer, pour permettre à un utilisateur d'avoir un aperçu de l'activité d'une application ou pour toute autre raison n'a, en définitive, pas grand chose avec le débat d'origine.

Au contraire, je dirais presque que la multiplicité des formats tend à montrer que la conception est, de manière générale, plutôt poussée, même si on peut regretter les choix effectués par certains ou même si elle arrive parfois trop tard (comprend par là qu'une conception plus poussée dés le départ aurait pu éviter de nombreux problèmes par la suite).

Mais le fait est là...

J'ai vu, pour tous les langages que j'ai pu manipuler, des gens qui faisaient leurs cas d'utilisations/diagrammes de séquence/diagrammes de classes et autres diagrammes UML, leurs MCD/MLD/MPD voire, pourquoi pas leur pseudo code/flowchart/NassiSchneiderman/Jackson après avoir écrit leur code ou créé leurs tables en essayant de l'adapter à ce qu'ils ont fait parce que "il faut bien le faire"...(sous entendu "mais je n'en vois vraiment pas *vraiment* l'utilité).

La seule chose est que, comme l'a fait remarquer (il faudrait que je vérifie, mais je crois) Luc (je présente mes excuses anticipées à luc et à celui qui l'a fait remarquer si ce n'est pas lui ), il est beaucoup plus facile de faire des erreurs de conceptions en C++ que dans un autre langage et elles se payent plus cher, essentiellement parce que c'est le prix à payer pour la liberté de choix...

Ce qui se passe, c'est qu'il est beaucoup plus facile de "cacher" son incompétence en conception derrière une technologie fortement liée à un framework plus important que derrière une technologie dans laquelle tu as une liberté quasi totale (allant jusqu'à la liberté de faire des c...ries)...

Mais, si tu veux tester la (l'in) compétence en termes de conception OO d'une personne, pose lui des questions relatives à demeter ou à LSP (ou à d'autres principes de base de la conception OO):

Même s'il ne sait pas t'énoncer ces lois et principes (parce qu'il ne connait pas forcément le nom ou le terme), mais s'il accepte sans rechigner un mutateur ou un accesseur simple, s'il accepte de faire hériter une classe carré de la classe rectangle (ou inversement), ou dans une certaine mesure, s'il a tendance à baser toute sa conception sur une classe de base de type "object" sans se poser la question de savoir s'il est réellement intéressant de le faire, tu pourra commencer à te faire du mouron quant à la qualité de sa conception...

Testes ensuite la capacité de la personne à exprimer en des phrases correctes et compréhensibles les relations existantes entre les différents éléments représentés par une représentation telle que UML ou merise... Ce sera sans doute une raison supplémentaire d'avoir des craintes

Et, si tu fais l'essai du coté des javaistes ou des C#istes, tu risque même de te faire bien plus de mouron que si tu le fais du coté des C++ien

Au delà de cela, s'il préfère une autre méthode à UML, mérise ou au nassichneiderman, le seul risque est d'arriver à certains quiproquo au sein de l'équipe, mais c'est le moindre mal

[Luc Hermitte]

Non, ce n'est pas moi
Mais le prix ne sera pas qu'intrinsèque aux nouveaux problèmes technico-conceptuels introduits par le langage. En cas d'erreur de conception (je ne parle pas d'une fuite qui se règle avec un vecteur ou un shared_ptr), les facilités de refactorisations ne sont pas forcément les mêmes entre les divers langages -- après, je ne me suis pas jamais amusé à comparer combien coute la correction d'un design full mutex et interbloqué vers un design orienté tâches et queues de messages dans les divers langages.

Et j'ai l'impression que +1 au "dans les autres langages les problèmes de conception seront tout aussi présents, voire plus".
Une tendance, que m'avait évoquée un collègue, en ce moment est d'embaucher des hordes de développeurs dans un langage plus simple (que je ne nommerai pas), on leur fait dégrossir le travail, on livre une première version. On réduit les équipes, et on y met pompiers et experts pour corriger les erreurs du troupeau.
Avantages : plus qu'un seul langage à connaitre dans l'entreprise, et on peut recommencer.

[CedricMocquillon]

Corrigez moi si je me trompe (Alp puisque tu suis la discussion...) mais je suis quand même d'accord avec le PO: entendons nous bien, je ne remet pas du tout en cause vos compétences respectives (c'est à lire vos posts que j'ai réellement progressé en C++) mais si on prend par exemple le tutoriel bien débuter en C++, les liens proposés ne parlent pas de conception.

Les principes "techniques" sont souvent cités RAII, polymorphisme statique, classes de trait ou de politique, couplage faible, mais rarement, on voit leur mise en œuvre concrète dans un projet orienté métier. On trouve de bon tutos sur dvp sur certains de ces points mais au final je pense que ce qu'il manque aux débutant et au PO ce serait un tuto sur la mise en application "concrète" de ces principes (appli de gestion de personnels, de stock-produits, etc...)

Encore une fois ne prenez surtout pas mon post comme une critique c'est juste ce que j'ai ressenti également lorsque j'ai commencé le C++ "moderne".