Il y a des forumeurs aussi qui disent tout et n'importe quoi :ccool:
Version imprimable
Si on recherche le meilleur enseignement, je pense que AC++ est un bon début. Si on se pose la question - de manière objective bien sûr, sinon ça n'a aucun intérêt - " est-ce que donner les bases du C++ en commençant par le C est la meilleur solution ? " , on peut y répondre par "non". AC++ le montre très bien.
Pour ma part, en tant qu'amateur ( pour l'instant ) , AC++ m'a appris à code assez rapidement ( dans le sens : utiliser les bons outils pour gagner du temps ) et à ne pas me préoccuper de certains détails qui compliquent inutilement le code ( principalement des choses que le C++ à hérité du C ) . Du coup, j'ai plus de plaisir à programmer.
La question touchant l'enseignement me touche(ra) beaucoup d'ici quelques semaines. Mais pour être honnête, il ne faut pas reporter ( AMHA ) toute la faute sur les profs : ils ont certes un rôle à jouer, mais leurs employeurs en ont aussi un. Ils y gagneraient beaucoup ( satisfaction du niveau des élèves en sortant, ou la renomé si ça les intéresse ) à fournir des cours pertinents pour les ( anciens ) professeurs et les mettre à niveau.
Non ce n'est pas la meilleure solution de commencer comme cela mais ce n'est pas ce que je disais non plus.
Je disais que dans un programme d'enseignement C++ s'arrêter sur le C un temps n'est pas pour moi une erreur ne serait-ce que pour voir les différences fondamentales. Et cela devrait faire parti de l'enseignement de montrer que ce sont 2 langages différents autant le faire dans un cours C++ non ? Probablement pas d'intro mais de conclusion ?
Il ne faudrait pas oublier que c++ a un sérieux problème (tout comme perl 6) :
Il faut des années, si ce n'est des décades pour que des compilateurs implémentants correctement le dernier standard en date soient au point. Ce n'est pas le cas des autres grands langages (à part, ok, perl 6). Des "bonnes pratiques" tant en terme d'idômes que de conception ne peuvent dès lors pas se répendre le jour même de la release. En gros, tout le monde nage dans le flou, à commencer par le commité de standardisation (qui, soit dit en passant, doit faire un boulôt parmis les plus complexes que l'intellecte humain puisse supporter). Le récent retrait des concepts en est la preuve flagrante: tout ça est chaudard, très très chaudard à gérer. Il ne faut dès lors pas s'étonner que ça parte dans toutes les directions, à commencer par les premiers visés: les utilisateurs. Heureusement, certains courants se dégagent (à grand coup de hacks, tricks et macros si nécessaire, du vrai c++ quoi) : boost, Qt que certains citent, même si quand on y réfléchit, c'est un peu de la triche quelque part..
On notera tout de même que malgré ces formidables obstacles, c++ a gardé une longueur d'avance sur ses concurrents directes (non, lisp est hors catégorie :mrgreen:). La STL, la programmation générique, c'est quand même plus ambitieux que le model tout objet à base de classe, finalement vieillo, que l'on retrouve chez ses voisins.
Pour reprendre la question originale (oui, je sais, ca fait loin) le coté multi-paradigme m'a toujours semblé plus une conséquence imprévue des évolutions techniques du langage, plutôt qu'une cause première de ces dites évolutions.
En fait, j'ai l'impression qu'il y a 3 "sous-langages" en C++ : le C, L'Orienté-Objet et le Template.
Ce qui induit le problème d'avoir une seule "conception technique" qui utilise jusqu'a 3 concepts différents. :P
Dans les projets que j'ai côtoyé, on a toujours essayer de mettre des règles strictes pour se cantonner à un seul concept (généralement l'orienté-objet). Je ne sais pas si c'est pareil pour les "pros" du C++, mais jongler avec ces 3 concepts est assez délicat dans un projet.
Oui, c'est l'analyse de Scott Meyers (et ses acolytes). En plus du "Template" pour la généricité, il y un pan tout entier pour la génération de code. L'aspect fascinant c'est qu'on ne finit pas de découvrir ce qui peut ressortir de l'imbrication de ces 4 conceptes. C'est pas java ou c# qui peuvent se vanter de ça (avec troll :mrgreen:)
Le c++ est un langage téchiniquement difficile, donc il est normal que les développeurs qui l'utilisent, passent plus de temps à parler technique que les développeurs java et .net
C++ langage élitiste?
En fait, cela fait même davantage si l'on prend en compte (pour la partie générique) les bibliothèques utilisées (avec ou sans boost, iostream intensif ou non), et (pour la partie POO) des habitudes divergentes (héritage multiple ou non, grandes hiérarchies abstraites ou petits héritages indépendants, surcharge ou non d'opérateurs).
C'est un problème tout à fait réel en entreprise... Quand on embauche un développeur C++, on doit s'assurer au préalable qu'il parle le même dialecte que celui utilisé dans le projet en cours... Sinon on est partis pour des heures de débats stériles, des réécritures et leur cortège de régressions, et souvent une démission à la clef.
En fin de compte, on a presque autant de dialectes que de programmeurs, ce qui fait du C++ une option dangereuse si l'on doit programmer en équipe.
Dans ce contexte, la voie C/C++ (c'est à dire la branche conservant un fort passif C) est souvent la solution de sécurité, ou alors, c'est la voie "orientée bibliothèque", par exemple autour d'un framework "à tout faire", genre Borland, ou MFC.
Francois
non mais à vous écouter on dirait que c'est super compliqué.
J'ai été formé à faire du C++ standard ( pas à l'école ) et j'ai moi même formé toute une équipe et ça n'a pas posé de problème.
Je fais du C++ en milieu industriel et.. ça marche. ( et je n'utilise pas de "framework" à tout faire externe )
Je cotoie des développeurs JAVA ( il y en a des sympas :P ) et eux aussi ont leurs problèmes qui me paraissent totalement ésotériques.
C'est vrai qu'on devrait forcer les récents embauchés à lire Meyers, Alexandrescu et/ou Sutter avant de les lâcher dans une équipe de développement…
… dans un monde idéal :(.
À mon avis, la « complexité » du C++ vient des gens qui ne s'adaptent pas. C'est aussi simple que ça.
et en parlant des bonnes références, la première fois ou j'ai découvert le site http://www.gotw.ca/gotw/ de herb sutter ou le but est résoudre quelques problèmes, je me suis rendu compte que je n'est jamais fais du vrai C++ avant.
je crois aussi que lors de l'enseignement on doit aborder des problèmes réels et qui sont formulés par des gens qui ont pas mal côtoyé l'entreprise pas ceux qui ont passer la majorité de leur temps a l'université entre thèse de doctorat et cours.
je ne les ai jamais lu, mais l'expérience dans tout un tas de langage/domaines (10 ans maintenant) me permettent de bien voir les conneries a ne pas faire et dans plus d'une techno...
ensuite il faut savoir être logique et pragmatique. un bon esprit cartésien aide pas mal.
Seulement si le reste de l'équipe les a déjà lus, non? Parce que sinon, ça risque d'être un peu sportif, à la cantoche le midi... (et je ne donne pas cher du nouveau...)
Non, sérieusement, la vraie difficulté, c'est cette évolution entre le C/C++ des programmes qui tournent aujourd'hui, et le C++ moderne qu'on voudrait voir dans ceux de demain (sachant qu'il sera probablement déjà ringard à l'époque).
L'université et la recherche auront toujours une longueur d'avance sur l'entreprise. Le problème de l'informatique en entreprise, c'est d'améliorer progressivement ses méthodes de programmation, et ceci demande des ingénieurs qui connaissent à la fois les anciennes pratiques et les modernes (et, si possible, ont assez souffert sous les anciennes pour avoir eu envie des modernes...).
Pas facile...
Francois
Je dirais qu'au contraire, ce sont ceux qui sont les plus enclins à lire les bonnes références.
Plusieurs de mes profs de maths ont un excellent niveau en C++ (maitrise de la POO en C++ et de la programmation générique, l'un ayant écrit du code utilisant du code utilisant les expressions templates).
Enfin, dans tous les cas, je pense que tu as une vision ... assez particulière du monde de l'entreprise et de la recherche.
en tout cas a l'université ou j'etais en france la conception c'était les diagrammes UML, et faire de la recherche est un métier noble mais proposer des solutions adaptés a l'entreprise ou les contraintes ne sont pas du tout les mêmes qu'a l'université, est une autre chose, a part si la reforme passe en france pour que ça soit comme aux USA:)
n'interprète pas encore ce que je dis comme insulte aux chercheurs , c'est juste c'est pas le même environnement et d'après mon expérience l'université a des principes beaucoup plus idéalistes de ce qui se passe en entreprise, et finalement c'est comme un enfant qu'on lui dit que tout va bien surtout t'inquiète pas et a 23 ans on le met dans la jungle.
Et essaye de remonter dans tes souvenirs et essaye de comparer la qualité du cours d'un prof qui côtoie l'entreprise et un autre qui reste qu'a l'université, en tout cas en ce qui me concerne il ya une différence.
et sincèrement quel moyen on donne a la recherche en france pour être au top surtout pour tout ce qui est technologique, je ne vais pas entrer dans la politique mais ils ont un budget médiocre.
Enfin j'essaye de voir la réalité comme tel pas comme je veux quelle soit,et si les profs sont en général très bons comme tu le dis pourquoi on arrivent plus a avoir sur le marché de bons profils C++.
Le C++ cache beaucoup moins de choses et sollicite davantage le programmeur au niveau des choix possibles. Comme toujours, le prix de la liberté, c'est la responsabilité.
Je dirais donc personnellement qu'il est plus facile d'être un mauvais programmeur en C++ qu'en Java/ .Net, ou encore qu'un mauvais programmeur fera beaucoup plus de dégâts en C++ que dans un autre langage. La difficulté de trouver des bons programmeurs en C++, c'est la difficulté de trouver des bons programmeurs tout court - c.a.d des mecs qui s'intéressent un minimum à ce qu'ils font.
Le C++ accentue davantage tes lacunes en programmation. Est-ce la faute du langage ou du programmeur ? Certainement les deux.
Sans compté que Qt utilise des meta data qui permet de manipuler une classe sans réellement la connaitre. Ce qui permet de faire des scripts (javascript) pour manipule ces classes. Et ils vont de plus en plus loin. Il faut voir ce qui est prévu pou la 4.6 ( fin d'années)
*de plus en plus de module utilise des plugin qui permet au code d'utiliser de nouvelle techno trés simplement et sans une ligne de code en plus. Comme l'utilisation de OpenVG pour l'accélération des traitement 2D
* un module d'animation et de state machine
* une techno nommé déclarative ui qui va permet de faire des ihm encore plus rapidement et simplement avec si besoin des animation. Leur démos sont très demonstratif.
* encore beaucoup de choses.
Et tout cela pour windows, linux, mac os, diverse os mobile et maintenant certain os temps réels.
Je t'assure qu'avec Qt, le C++ n'as quasiment plus rien à envié à C# ou java. C'est pareil avec d'autre lib bien sure.
Tu parle d'un manque de conception?? ben Bosst, Qt et bien d'autre lib ne serait pas aussi puissante sans conception, non?
Sincèrement, tu n'es pas loin de la vérité à mon avis, mais tu n'y es pas.
Dans la recherche, il y a de tout. Dans l'entreprise, il y a de tout. Par contre, on est d'accord pour la recherche niveau budget...
Après, les profs, ça dépend. Il n'existe pas de vérité ultime sur le sujet je pense. Seulement, il semblerait qu'on se trouve à deux pôles opposés alors on ne tombe pas toujours d'accord ;)
juste pour précision je parle de manque de conception dans les projets réalisés dans les entreprises du a l'intérêt croissant des développeurs a la technique mais je parle pas des librairies les plus utilisés STL, BOOST et bientôt peut être QT qui sont très bien conçu.
je ne sais pas si t'est d'accord avec moi que les profs qui côtoient l'entreprise sont en général plus bon que ceux qui ne la côtoient pas puisqu'ils arrivent a prendre en compte les contraintes des 2 mondes université et entreprise?
si oui pour une fois on sera d'accord :)
Ca c'est facile... Ca tient au marché du travail.
En France, une personne un peu douée en sciences finit avec un bac S, si elle est assez forte, elle va faire une prépa scientifique, pendant laquelle elle va ingérer beaucoup de maths et de physique, et apprendre à travailler efficacement. Si elle est assez forte, elle intègrera (en 3/2, forcément), une école d'ingénieur, qu'elle prendra probablement dans l'ordre de leur classement (je ne sais pas si ca a beaucoup changé, mais de mon temps c'était assez simple, Ulm, l'X, les mines et Centrale Paris à peu près à égalité, puis les Pont, les Télécoms, SupAero, Supelec, l'Ensta, les ENSI dans un ordre assez précis, ENSIMAG en tête, et ainsi de suite... Très peu de taupins choisissaient leur école par rapport à un centre d'intérêt, de toutes façons, un premier de la classe de 20 ans, ca ne sait pas trop ce que ca veut faire dans la vie)
Tout le système est organisé autour de la sélection en sciences, donc pas de débat, les bons en science finissent dans les grandes écoles, où ils ont de meilleurs profs, et apprennent à apprendre... Le système des prépas a tendance à creuser l'écart au sein d'une classe d'age : on fait travailler les plus doués, qui s'améliorent plus vite, et en plus, grace aux anciens élèves, on les aide au départ...
Le problème, c'est qu'en sortie d'école, ces bons, ils préfèrent bosser dans la finance, la banque, l'assurance, que faire de l'informatique. Il y a bien sur quelques fanas, mais ceux là finissent soit dans la recherche (c'est peut être bien eux, les bons profs dont parle Alp), soit à l'étranger (il y a quelques années, les salaires offerts aux Etats Unis étaient voisins des salaires français, sauf que les salaires américains étaient en dollars, et les français... en francs... y'a plein de français, en californie, dans les boites d'informatique, ou dans les labos de la cote est)
Donc, le top du top... il y en a très très peu qui arrivent sur le marché du travail en informatique.
Un cran en dessous, tu vas avoir de plus petites écoles et la fac. Là il y a pas mal d'informaticiens, mais ce sont des moins matheux, avec un langage un peu technique et abstrait comme le C++, il vont un peu souffrir (même avec de bons profs). Et puis, le C++ est peut être élitiste, mais je ne crois pas qu'il soit perçu comme le langage de l'élite. Pour pas mal de jeunes, le C++ c'est le langage moderne de papa, un rien vieillot. L'informatique marche pas mal aux effets de mode, ça se ressent sur les informaticiens.
Aussi, en France, le tertiaire (la gestion) paye généralement mieux que les secteurs industriels. Si tu es informaticien et que tu veux gagner des sous, il vaut mieux travailler dans l'informatique de gestion... Et là, encore, le C++ c'est pas ca...
Honnêtement, je ne crois pas que ce soit la faute des profs, ou en tous cas pas entièrement.
Francois
t'a raison on ne peut pas tout mettre sur le dos des profs, et d'un autre coté actuellement le C++ est enseigné très rapidement pas comme a l'époque ou le c++ était dominant , actuellement il ya dotnet et java.
donc ce qu'on demandent aux profs est surtout de bien aiguiller que de tout enseigner puisque c'est mission impossible vu le temps alloué pour C++ maintenant, et a mon avis si un prof ne côtoie pas l'entreprise il aura du mal a bien aiguiller sur les bonnes références et les bonnes pratiques, peut etre je me trompe puisque encore une fois je ne parle que dans mon expérience et bien sur je ne peux pas généraliser.
et l'autre raison qui peut être la plus influente c'est les boites de services , il y en a tellement en france et il essaye de placer des développeurs a tout prix, on vend quelqu'un comme expert ou architecte même s'il ne connais pas trop a l'architecture.
et je pense que les boites de services qui ne pense aux développeurs que comme des numéros pour les placer indépendamment de leur compétences a son rôle dans cette affaire.
par contre les éditeurs de logiciels sont plus organisés et en général ils sont obligé de bien faire les choses et ils se donnent les moyens, parce que le produit est censé être vendu a plusieurs clients donc il faut bien faire pour pouvoir gérer facilement les retours.
mais pour les projets lancés juste pour une boite donnée soit en régie ou en presta on fait vite et on trouve toujours des arguments (budget, planning ou autre).
Et j'ai une question pour ceux qui ont déjà travailler dans d'autres pays Angleterre,USA ou autre: est ce que c'est la même chose qu'en france ou les boites de services dominent le domaine d'informatique?et Merci d'avance.
En parlant de la programmation déclarative de l'interface graphique effectivement ça peut avoir pas mal d'avantage, a part le fait que ça facilite le design ça aide aussi a découpler le design de la couche métier.
et le monde C++ était le premier a proposer une tel programmation avant même XAML ou Flex il s'agit de ce que propose Mozilla avec XUL.
XUL est très puissant aussi mais son problème ça devient vite un casse tête par manque d'outil adéquat et aussi par manque d'abstraction.
En fait Firefox est un navigateur mais aussi un conteneur d'application XUL et le navigateur n'est lui même qu'une application a base de xul exécuté dans ce conteneur et vous pouvez développez vous même des applications a base de XUL est les exécuter dans ce conteneur.
je rebondis sur ce sujet parceque je trouve dommage qu'a un moment donnée C++ etait en avance par rapport aux autres langages mais le manque d'abstraction de la complexité rend quelque fois des libraries trés puissantes utilisable que par une élite.
et d'aprés mon experience il ya des années avec XUL c'etait non productif.
J'espère que QT propose une bonne alternative très facile a mettre en œuvre.
Question : De ce que je connais de Qt (V3, il y a quelque temps), je le met dans la même catégorie en terme de philosophie, facilité d'usage, de possibilités de customisation que les windows forms de .NET, ou la VCL de Delphi.
Depuis quelque temps, j'utilise WPF (du .NET encore), qui ma l'air de fournir des concepts qui vont vraiment plus loin que ça, en particulier et terme de liberté de customisation d'apparence (typiquement, un élément d'une liste déroulante, ou un bouton, ou presque s'importe quoi est un conteneur pouvant contenir des sous éléments) et par le binding entre les objets dans le code et les propriétés des éléments de l'IHM.
Est-ce que Qt va aussi dans cette direction ? Est-ce qu'il y a un équivalent en C++ de ces fonctionnalités ?
C'est moins orienté "400% applications de gestion", tu ne peux pas faire de data binding par exemple. Mais tu peux customiser tes widgets à mort, par le biais de l'héritage, et rajouter des trucs à toi. Donc potentiellement, c'est la même chose qu'avec ce que tu décris.
Par contre, les différents mécanismes de Qt, et les outils qui existent ou vont venir, tout ça rend son utilisation très facile. J'ai bien envie de dire qu'on attendait ça depuis longtemps en C++.
Le système de signal/slot, sa gestion des évènements, et je trouve que son utilisation est assez intuitive en plus de tout ça.
Après, ça dépend des goûts et habitudes de chacun. Mais s'ils arrivent à rendre les choses encore plus déclaratives, ça va vraiment vraiment devenir un framework de référence (si ça ne l'est pas déjà :mrgreen:) pour le C++.
Je ne connait pas du tout adobe.ASL et commence avec qml.
Tu peut regarder ici :
http://labs.trolltech.com/blogs/cate...eclarative_ui/
et il y as des binaires d'exemple ici :
ftp://ftp.trolltech.com/declarativeui/
Il suffit d'utiliser qmlviewer et de visualiser un fichier qml.
La demo de flicker ne contient aucune ligne de C++.
J'ai remarquer que le QML pour déclarer l'UI n'est pas en XML mais un format spécifique, alors je me demande pourquoi laisser le langage standard qui est très mature ou il ya plusieurs outils d'une part et une manière de validation par xsd d'autre part et on cherche a faire du spécifique.
c'est ce qui me gêne toujours en C++, on laisse la manière la plus intuitive et on fait compliqué , peut être on se dit non ça sera trop simple, ajoutant une couche de complexité pour que ce soit du vrai C++ :)
Enfin je retire ce que j'ai dis si c'est du XML , en tout cas en voyant leurs exemples c'est pas le cas.
Qt 4 permet divers customisation :
* style
* stylesheet
* QPainter
Pour les list/ tree/table leurs Model/View Programming permet de faire tous ce que tu veut (à ma connaissance) grâce au delegate
Je sais pas trop si j'ai répondue à ta question.
je parle pas de l'écrire a la main , mais je parle d'un langage de représentation qui est mature et il a un grand historique d'outils et d'expérience.
alors pourquoi chercher a faire autrement?
Pour l'évolution de librairie ou de langage a mon avis il doit aller vers un sens ou on passera même pas 10% de notre temps sur la partie technique, beaucoup de choses doivent être transparentes.
prenons comme exemple la langue francaise , on fait pas attention a ces mécanismes a chaque fois qu'on veut dire une phrase c'est tout a fait transparent , on se concentre plus sur le message qu'on veut véhiculer.
c'est pour cela que chaque évolution doit faire au maximum abstraction a la complexité derrière.
et adopter ce qu'on sait déjà faire en terme de représentation me parait le minimum a faire pour aller vers ce but.
J'y jetterai un oeil, merci.
adobe.ASL est géré ici.
Côté démo, vous pouvez jeter un oeil à begin sur lequel on peut glisser les paires de fichiers Adam/Eve (contraintes/~display), ce qui rend le prototypage particulièrement aisé.
Chez adobe.ASL, les choix de design sont expliqués/justifiés/détaillés.
Citation:
Envoyé par ASL overview
Je ne sais pas trop non plus. Je vais lire les liens que tu as mis.
A ton tour, je t'invite à ton tour à lire l'article http://www.drwpf.com/blog/ItemsContr...9/Default.aspx
Il entre peut-être un peu trop dans les détails pour qui ne veut pas utiliser WPF, mais il montre bien ses capacités en terme de customisation. La particularité étant que toute customisation d'apparence se fait sans vraiment écrire de code.