Il y a des forumeurs aussi qui disent tout et n'importe quoi :ccool:Citation:
Envoyé par white_tentacle
Version imprimable
Il y a des forumeurs aussi qui disent tout et n'importe quoi :ccool:Citation:
Envoyé par white_tentacle
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.Citation:
Envoyé par hegros
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.Citation:
Envoyé par hiura
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.
Certes, et Stroustrup y consacre d'ailleurs tout un chapitre, complet et très détaillé, dans son dernier livre destiné aux novices "Programming and Principles using C++". Sauf que ce chapitre "The C programming language" est le chapitre 27, pas le chapitre zéro.Citation:
Envoyé par hegros
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.
Citation:
Envoyé par Arzar
merci de confirmer mes idées par le concepteur du langage :mrgreen:
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:)Citation:
Envoyé par pseudocode
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).Citation:
Envoyé par pseudocode
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
C'est ce qui fait la beauté de ce langage.C'est un langage que l'on s'approprie de façon très intime.Citation:
Envoyé par fcharton
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.
non mais ça me parait pas aberrant dans une équipe de dev qu'il y ait au moins une personne ( le responsable technique? ) qui s'intéresse au langage qu'il utilise. Si ça c'est de l'utopie, on est mal barré.Citation:
Envoyé par Florian Goo
c'est pas un langage de sociopathe quand même :DCitation:
Envoyé par Florian Goo
Je ne suis pas un pro, mais avoir lu les 3 ou 4 bouquins qui font autorité me paraît être le stricte minimum pour une personne censée gagner sa vie avec le c++. Lire Alexandrescu ça devrait être obligatoire dès l'école.Citation:
Envoyé par Florian Goo
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.Citation:
Envoyé par metagoto
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...Citation:
Envoyé par metagoto
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...)Citation:
Envoyé par Florian Goo
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.Citation:
Envoyé par Issam_Lahlali
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.