Utilise Qt via Qt Creator (IDE écrit par la boîte qui fait Qt) ou le plugin Visual C++, tu verras. Je pense créer des IHM plus vite que les débutants C# et aussi vite que les expérimentés de C# (étant assez familier avec Qt). De plus, Qt tourne très bien sous Linux, Mac, Windows et de plus en plus de smartphones.
C'est sympa, pratique et très portable, sans mettre de côté l'intuitivité une fois que tu as compris comment cela fonctionne.
Par contre, je suis d'accord pour dire que le fait que beaucoup de choses ne soient pas comprises dans la bibliothèque standard n'aide pas le C++ à être adopté en entreprise. C'est l'une des choses qui le fait paraître pour un langage "élitiste" ou je ne sais quoi.
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Je crois que ce qu'il voulait dire, c'est qu'UML ne permet pas de modéliser certains aspects qui sont possibles en c++. Donc, UML est certe neutre en terme de langage, mais finalement, il te bride dans certains langages.UML peut éventuellement [1] pousser à utiliser un paradigme mais est bien neutre en terme de langage.
Le modèle UML pourra être implémenter dans tout langage supportant nativement ce paradigme ou offrant des mécanisme pour l'émuler.
Certes, certains aspects intéressant du C++ ne seront pas utiliser/modéliser mais le modèle pourra bien être implémenter en C++ et dans nombre d'autres langages, en ce sens UML est bien neutre en terme de langage.
La conséquence, c'est que si tu modélises en uml, tu te retrouveras à choisir java ou csharp comme langage, parce que tu n'auras jamais besoin de fonctionnalités qui n'y sont pas (elles ne sont pas non plus dans uml). Du coup, ce n'est plus vraiment neutre.
Rien que les classes imbriquéesAurais-tu des exemples de conception où le mapping UML/C++ n'est pas bijectif ?
"Never use brute force in fighting an exponential." (Andrei Alexandrescu)
Mes articles dont Conseils divers sur le C++
Une très bonne doc sur le C++ (en) Why linux is better (fr)
Je ne suis pas pro d'UML, mais ces stéréotypes ne m'ont jamais semblé qu'une rustine, qui permet d'indiquer des choses, certes, mais pas vraiment de les visualiser, de communiquer dessus. Peut-être que je me trompe ?
Comment indiquer qu'un template demande des objets copiables et triables ?
Comment indiquer les fonctions libres associées à une ou plusieurs classe ?
Comment indiquer que la relation entre deux objets est une possession partagée (shared_ptr, ou autre), une non possession (weak_ptr, T*, ou autre), une possession unique (unique_ptr, ou composition, ou autre) ?
Comment indiquer qu'un template est spécialisé pour un type, une famille de types ?
Comment indiqué que dans une classe, une série de fonction peut être appelée depuis plusieurs threads en même temps ?
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
faire une bonne conception ne veux pas dire forcement adopter UML, certes c'est un langage puissant pour représenter la conception et la documenter et aussi ça permet une bonne communication au sein de l'equipe mais il ya des règles de bases de conceptions qui peuvent nous faire gagner beaucoup de temps.
Prenons par exemples les patterns GRASP et intéressant nous juste aux deux principes: Couplage faible et Cohesion forte.
Malheureusement on se rend compte des dégâts du couplage fort que lorsqu'on veut faire une migration ou une évolution majeur.
et on oublient que le couplage fort a un impact général sur toute l'entreprise, prenons un exemple concret sur lequel j'ai bosser, notre projet se basait sur Corba or il n y avait pas de couplage faible et du coup la complexité corba se trouvait a tout les niveaux du projet, et la conséquence c'est que les ressources humaines avait du mal a chercher les développeurs vu qu'ils doivent maitriser Corba.
des fois on oublient qu'un problème de conception impacte tout les acteurs de l'entreprise.
non uml n'est pas la seul démarche de conception viable, il en existe tout un tas plus ou moins adapté en fonction de tes besoins.
la conception et les choix qui y sont fait sont cruciaux quelque soit le soft que tu developpe.Malheureusement on se rend compte des dégâts du couplage fort que lorsqu'on veut faire une migration ou une évolution majeur.
et on oublient que le couplage fort a un impact général sur toute l'entreprise, prenons un exemple concret sur lequel j'ai bosser, notre projet se basait sur Corba or il n y avait pas de couplage faible et du coup la complexité corba se trouvait a tout les niveaux du projet, et la conséquence c'est que les ressources humaines avait du mal a chercher les développeurs vu qu'ils doivent maitriser Corba.
des fois on oublient qu'un problème de conception impacte tout les acteurs de l'entreprise.
cela aura un impact fort sur les performances de ton application, sa scalabilité, maintenabilité de l'architecture, ...
C'est pour cela qu'il ne faut jamais faire l'impasse dessus.
j'ai l'impression que ton projet te déprime? je me trompe?
Pas du tout, les exemples que je cite font partit de mes expériences que j'aime partager pour que d'autres les evitent.
par contre ce qui me déprime c'est le grand intérêt de la communauté c++ a tout ce qui est technique.
dans les années 90 c'etait comprehensible vu qu'il nyavait pas de resources techniques sur le web et le risque majeur c'etait la technique.
Mais de nos jours on trouve tout ce qu'il faut pour resoudre les problémes techniques mais malheureusement les attitudes n'ont pas changer , on s'interessent toujours plus aux astuces techniques.
Encore une fois c'est pas la faute au langage mais a a la communauté qui contribue a laisser la technique le roi de C++![]()
Une agrégation forte stéréotypée "inner" peut faire l'affaire.Rien que les classes imbriquées
En stéréotypant les méthodes par exemple.Comment indiqué que dans une classe, une série de fonction peut être appelée depuis plusieurs threads en même temps ?
Il est possible de définir des contraintes personnalisées utilisées dans des expressions OCL.Comment indiquer qu'un template demande des objets copiables et triables ?
...
Concernant les templates, s'ils induisent un paradigme vraiment spécifique et riche il est possible de définir un "Template profile".
UML a été conçu pour être extensible et doit donc permettre d'exprimer toute conception; cela se faisant plus ou moins simplement : dans les cas basiques via les stéréotypes qui permettent de changer la sémantique des éléments de base du langage, et dans les cas plus riches via la définition d'un nouvel ensemble d'éléments qui vont permettre de modéliser de manière standardisé des conceptions dans des domaines spécifiques : il existe par exemple un profile pour les tests, l'UML Testing Profile.
Un tel outil de représentation n'a d'intérêt que :
- Si la représentation est claire, parlante
- La représentation est partagée entre les utilisateurs de l'outil
- Les outils logicielles l'intègrent bien
J'ai des doutes sur les trois points si je dois définir moi même une extension au langage UML pour les template.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Partant du principe qu'avec UML on peut tout représenter, mais a mon avis il faut différencier conception et UML , on peut faire une conception médiocre avec UML comme on peut faire une conception géniale sans UML.
UML est un moyen pour documenter et facilite la communication mais ca ne veut pas dire qu'on a fait une bonne conception, et meme l'absence d'outil puissant pour synchroniser le code et les diagramme UML font qu'en general on a des diagrammes UML obsoletes.
ca parait évident comme remarque mais de plus en plus de développeurs surtout ceux qui sortent de l'école croient qu'ils font de la conception s'ils utilisent UML et même pire étant étudier un cours de conception dans une université en france on a fait que l'UML c'est comme si tu veux étudier la philosophie et on t'enseigne le français![]()
Tout à fait, UML n'est qu'un langage, même pas une méthodologie.
Il existe des outils de synchronisation automatiques, mais pour être réellement pertinente il faut que leur utilisation s'inscrive dans une démarche plus profonde de MDE.
Ce problème d'enseignement est malheureusement à généraliser à toutes les sciences informatiques, en particuliers la programmation.
Oui, la grande question est quand ce qu'ils lachent ?Il existe des outils de synchronisation automatiques, mais pour être réellement pertinente il faut que leur utilisation s'inscrive dans une démarche plus profonde de MDE.
Car comparé au Java/C# (les autres principaux langages du moment) le C++ est quand même beaucoup plus complexe, riche et puissant (pas de troll).
Si le code est "simple" (utilisations basiques des classes, ...), les outils peuvent encore faire des diagrammes pas trop mauvais (même plutôt bons), mais dès que tu pars sur des trucs bizares à coup de template dans tes classes, les outils ne suivent plus (ou alors pas ceux que j'ai utilisés). Ils ne sont plus capables de faire des diagrammes corrects, il faut éditer le diagramme à la main après et perso, j'ai autre chose à faire.
Un autre gros problème, c'est pour représenter les différents paradigme que peut utiliser le C++ dans un même programme, UML est "limité" à de l'objet.
"Never use brute force in fighting an exponential." (Andrei Alexandrescu)
Mes articles dont Conseils divers sur le C++
Une très bonne doc sur le C++ (en) Why linux is better (fr)
Ce n'est pas un troll mais un fait : en tant que langage C++ est le plus riche des trois : rien que la possibilité de faire de la méta-programmation le place en terme de possibilités de programmation loin devant Java ou C#.Car comparé au Java/C# (les autres principaux langages du moment) le C++ est quand même beaucoup plus complexe, riche et puissant (pas de troll).
De même de la possibilité de faire de l'héritage multiple, même si cela est plus commun dans les langages dynamiques comme Python.
Il semble que parmi ces trois langages C++ soit le seul à ne pas avoir cédé aux dogmes du type "l'héritage multiple est à proscrire".
Ce dernier posant de gros problèmes de conceptions quand il s'agit d'implémenter des patterns simples comme l'observateur.
Pour en revenir à la question initiale le C++ permet d'établir des conceptions plus riches, impossibles à mettre en oeuvre dans d'autres langages; le problème est alors le nivellement par le bas, au plus grand dénominateur commun, poussant à ignorer ces possibilités afin d'assurer la cohérence avec les autres développement en Java ou C#.
Peut être que tous ces débats techniques viennent de débutants qui ne maitrisent pas totalement le langage, et que lorsqu'ils s'intéressent à la conception ils se renseignent ailleurs ?
Pour moi la conception est quand même très indépendante du technique, et les débats à propos de conception sont peut être faits au sein des équipes en entreprise et pas sur internet, contrairement à tous ceux qui font du "C++ à la maison" qui ont souvent des questions à poser.
Effectivement et même dans un monde idéal elle doit être indépendante du langage ou de la technologie utilisé c'est l'approche MDA.
mais dans le monde réel la conception dépend beaucoup du langage vu que chaque langage a des mécanismes différents, par exemple la possibilité de l'héritage multiple et des mots clés comme friend en c++ influencent sur la conception.
mais il faut toujours se poser la question: est ce logique qu'après plus de 20 ans d'existence de C++ on bataille avec les fuites mémoires,le fameux 0xC0000005 et d'autres soucis techniques.
parmi les principes de la POO est de faire l'abstraction a tout ce qui est compliqué, d'autres langages ont déjà passé a l'orienté aspect pour que le code ne contient que le métier.
Tu parles de fuite de mémoire, on en revient donc bien à la technique. Or si on utilise les bons outils ainsi que les idiomes à notre disposition alors ce n'est plus un soucis. (cf les smart_ptr et le RAII). On peut donc se concentrer sur la conception.
C'est sûr que le C++ n'a pas la même facilité que les autres langages, MAIS je ne vois toujours pas en quoi ça prouve que le C++ se passe de conception. Peut être qu'il faudra passer un peu de temps sur quelques bugs, mais ça n'empêche pas d'avoir fait la même conception à la base que pour un autre langage non ?
En fait je ne comprends pas trop le but de ton post, si le C++ ne correspond pas au niveau d'abstraction que tu souhaites, il suffit de changer de langage. Car au final chaque langage ou outil sera meilleur qu'un autre pour un certain cas de figure.
juste pour donner un exemple concret d'un des principes de conception ou on parle moins dans la communauté C++ et c'est devenu a la mode pour la communauté java et C#, il s'agit du principe des contrats qui est representé par des interfaces pour ces deux derniers et par une classe abstraite pur pour C++.
les interfaces jouent un rôle important lors du découplage et ça permet d'isoler des fonctionnalités dans des composants, le développement et la maintenance se simplifient.
C'est tout a fait possible en C++ mais on trouve moins cette culture pour les développeurs C++ par contre juste des articles pour débutants en C# ou java parle de l'intérêt de ça.
Partager