[formation] C et C++ ensemble ou séparé.

Citation:

---

Envoyé par Mac LAK

Plus sérieusement, même si ce sont deux langages différents avec un "tronc commun", je fais autant de C++ "pur et dur" que de "C with classes" que de C "le dév qui murmurait à l'oreille des CPU"... Et c'est aussi grâce à ça que j'ai du boulot, d'ailleurs : je connais les deux langages, et je sais les faire cohabiter lorsque c'est nécessaire.

---

Le domaine de l'embarqué est certainement un de ceux où le C est encore nécessaire.

Citation:

---

Envoyé par Mac LAK

A mon sens, il est important de connaître les deux. La "guéguerre" pour savoir lequel des deux est le plus beau est encore plus stérile que toutes les autres guerres de langage, car ils restent quoi que l'on dise indissociables l'un de l'autre. Les API des OS sont toutes en C, par exemple, et ça n'a jamais tué un dév C++ d'utiliser ces primitives "C" dans des classes C++, non ? ;)

---

Je fais une nuance entre "connaître assez de C pour comprendre et utiliser une interface écrite en C" et "être capable de développer en C". Autant le premier point me semble nécessaire dans tous les cas, autant le second me semble inutile dans un grand nombre de contextes (en tout cas, en 12 de boulot en C++, je n'en n'ai jamais eu besoin).

Pour ce qui est des API d'OS en C, déjà, ce n'est pas forcément vrai (Next, Windows qui a des API en COM, et commence à proposer des API .NET par endroit), en plus, je suis loin d'être certain que ça n'ait jamais tué personne, par les bugs que ça a pu introduire, mais je n'ai pas d'exemple concret ;)

Mais surtout, c'est une chose très lourde qui rend l'utilisation de ces API lourde, peu intuitive et risquée.

La preuve, c'est le nombre de gens qui prennent une bibliothèque portable en C++ wrappant une partie de l'OS alors même qu'ils savent bien que la portabilité ne sera jamais utilisée, simplement parce qu'elle offre une API plus agréable d'emploi (par exemple boost::thread, boost::filesystem) ou qui développent eux même un wrapper par dessus l'OS, dès qu'il s'agit d'appeler la fonction plus d'une fois (exemple : J'ai écrit une série de fonction

Code:

---

1 2	template<class DestStringType, class SourceStringType> DestString string_cast<DestStringType>(SourceStringType const &str)

---

pour wrapper les fonctions de conversions de types de caractères de windows, pour accéder à la registry, je me suis fait ma classe qui gère les libérations de ressources...).

Par contre, moi je ne suis pas contre utiliser du code C dans un projet C++, mais alors en prenant certaines précautions:
. le code C en question soit propre (autrement dit, savoir programmer en C)
. que ce soit séparé: au moins que le code C soit dans des fichiers séparé (avec extern C{} etc.) ou mieux, dans une lib à part.

Bref, ne pas mélanger les deux finalement.

Salut,
Les pratiques ne changeront pas tant qu'on pensera que C et C++ sont suffisamment cousins pour être mélangés allègrement. Cependant, à un moment, il faut se confronter à la réalité : beaucoup de projets C++ - mais pas tous - mêlent les 2. Et souvent, les annonces que j'ai vu mentionnent 'C/C++' même quand il ne s'agit que de C ou que de C++. Et certains projets sont obligés d'avoir des couches basses en C et des couches métiers en C++ ... avec une partie commune. Pas facile de trancher :koi:
Ensuite vient la question de départ : faut-il enseigner conjointement le C et le C++ ? Est-ce que le C++ est encore enseigné en tant que langage objet ? D'après ce que j'entends, on a plutôt tendance à enseigner le Java comme langage objet. Le C++ n'arrivant à se glisser que comme seconde partie du cours de C :aie: D'où une partie du problème.
L'intéressant serait de faire venir un prof qui nous donne son point de vue avec ses contraintes d'enseignement, sa vision plus globale d'un cursus, etc. Sans quoi je crains qu'on ne prêche que des convertis.

P.S. : @rod : le catalan ce n'est que du castillan parlé dans le sud de la france. Alors que le gallego, non ! C'est différent : c'est une vrai langue :mouarf:

Citation:

---

Envoyé par 3DArchi

Et souvent, les annonces que j'ai vu mentionnent 'C/C++' même quand il ne s'agit que de C ou que de C++.

---

En général, on met les 2 parce que les programmes sur lesquels on travaille sont du C++ (en ce sens qu'on utilise la syntaxe du C++ et qu'on compile avec un compilateur C++) mais incluant des bouts de code qui relèvent davantage du procédural façon C que du C++ moderne.

Dire C/C++, c'est une façon de dire au programmeur : c'est du C++ mais attends toi à trouver des bouts de C dedans, et oui on sait que ce ne sont pas les bonnes pratiques, mais non, on s'en fout parce que ces bouts de C sont solides et testés.

C'est aussi un moyen de chasser les pinailleurs...


Quant à la séparation stricte dont parle RoD, souvent, on va récupérer une fonction, un bout de librairie, qu'on va utiliser telle quelle. Isoler ces librairies dans un module spécifique *parce que c'est du C* est possible, mais cela casse la logique du découpage en modules fonctionnels.

On en revient toujours au principe de réalité (je ne parle de la programmation C bas niveau qu'évoque Mac Lak, je ne la connais pas). Aujourd'hui, les offres d'emplois pour des developpeurs C++ portent majoritairement sur ces programmes hybrides, qui mèlent C et C++, souvent pour des raisons historiques.

La chance des développeurs C++, c'est qu'il y en a beaucoup, des programmes comme ca. Et qu'ils dureront pas mal de temps.

Le malheur des développeurs C++, c'est qu'on ne fait pas du beau C++ propre comme dans les livres...

Et la question pour les recruteurs, c'est de trouver des dev C++ qui seront suffisament enthousiastes pour faire progresser l'existant C/C++ vers un C++ meilleur, mais suffisament raisonnables pour ne pas se tirer une balle dans le pied la première semaine, en expliquant qu'il faut tout refaire...

Francois

Et tant que l'on perdurera avec cette approche non pinailleuse, on continuera à faire du C/C++ pénible à maintenir sur les nouveaux projets ...

Citation:

---

Envoyé par fcharton

En général, on met les 2 parce que les programmes sur lesquels on travaille sont du C++ (en ce sens qu'on utilise la syntaxe du C++ et qu'on compile avec un compilateur C++) mais incluant des bouts de code qui relèvent davantage du procédural façon C que du C++ moderne.

---

Pour avoir fait les 2 (C et C++) en embarqué ou en PC, mon ressenti est plutôt qu'on met les 2 car dans l'esprit du recruteur, c'est la même chose. Et que beaucoup de développeur 'ancienne' génération (dont j'ai longtemps fait parti) ne perçoivent pas forcément les différences.
In fine, tu as raison : il y a le ciel et il y a la terre. Et on vit sur terre donc il faut aussi savoir cohabiter avec la réalité ;)

Généralement, j'ai tendance à dire C∩C++ pour parler du sous-ensemble commun aux deux langages. Il m'arrive trop souvent de programmer ainsi, mais au moins j'en suis conscient.

Avant de repondre a la question, il me semble necessaire de determiner le contexte de la formation.

Quel est le public cible?
Quels sont les prerequis?
Quels sont les objectifs de la formation?
Quels sont les autres matieres?
Quels sont les volumes horaires assignes a chacune de ces matieres?
Quels sont les dependances? (Entre les matieres, avec des stages, ...)

Citation:

---

Envoyé par Luc Hermitte

Et tant que l'on perdurera avec cette approche non pinailleuse, on continuera à faire du C/C++ pénible à maintenir sur les nouveaux projets ...

---

Je ne crois pas... Il y a une évolution, lente, comme tout ce qui se fait dans le monde réel, mais bien réelle, de la façon dont on programme en entreprise.

Mais c'est lent, la STL commence à devenir la norme. Boost, c'est encore le futur, mais on commence à voir des templates utilisés de façon sérieuse.

C'est la réalité du métier, le C++, c'est souvent employé sur de gros programmes, gérés par des équipes importantes, et ayant de longues durées de vie. Ce sont des grosses machines, qui tournent lentement.

Francois

Citation:

---

Envoyé par Jean-Marc.Bourguet

Avant de repondre a la question, il me semble necessaire de determiner le contexte de la formation.

Quel est le public cible?
Quels sont les prerequis?
Quels sont les objectifs de la formation?
Quels sont les autres matieres?
Quels sont les volumes horaires assignes a chacune de ces matieres?
Quels sont les dependances? (Entre les matieres, avec des stages, ...)

---

Effectivement, c'est très pertinent comme remarque. Mais l'idée originale de ma question portait plus sur une réflexion générale, qui s'appliquerait à tous types de formations. Peut-être est-ce tout simplement impossible de généraliser autant... cela explique peut-être le troll?

Citation:

---

Envoyé par JolyLoic

Le domaine de l'embarqué est certainement un de ceux où le C est encore nécessaire.

---

Oh, pas que là : les couches bas niveau le requièrent aussi (driver, kernel, etc.) pour des raisons de performances. Certes, il est possible d'avoir du C++ quasiment aussi performant que du C, mais cela a un coût : inlining à outrance (= adieu la RAM), ou suppression des possibilités d'héritage (classes statiques) pour éliminer l'indirection induite par les classes qui, dans un tel domaine, peut parfois devenir rédhibitoire.

Citation:

---

Envoyé par JolyLoic

Je fais une nuance entre "connaître assez de C pour comprendre et utiliser une interface écrite en C" et "être capable de développer en C". Autant le premier point me semble nécessaire dans tous les cas, autant le second me semble inutile dans un grand nombre de contextes (en tout cas, en 12 de boulot en C++, je n'en n'ai jamais eu besoin).

---

Disons que c'est tout à fait normal si ce n'est pas toi qui développe lesdites couches basses... ;)

Citation:

---

Envoyé par JolyLoic

Pour ce qui est des API d'OS en C, déjà, ce n'est pas forcément vrai (Next, Windows qui a des API en COM, et commence à proposer des API .NET par endroit), en plus, je suis loin d'être certain que ça n'ait jamais tué personne, par les bugs que ça a pu introduire, mais je n'ai pas d'exemple concret ;)

---

Tu as un souci d'intéropérabilité avec les langages avec les API en C++, à cause de l'ABI. A noter d'ailleurs que COM est orienté objet, mais ce n'est pas de l'objet.

Citation:

---

Envoyé par MSDN

A COM interface is not an object. It is simply a related group of functions and is the binary standard through which clients and objects communicate. As long as it can provide pointers to interface methods, the object can be implemented in any language with any internal state representation.

---

Du coup, c'est portable et utilisable dans tous les langages de programmation supportant l'importation de fonctions C classiques (WINAPI). Pour ceux qui ne voient pas de quoi je veux parler, c'est en gros une structure avec des tas de champs qui sont des pointeurs de fonction.
Par contre, je te confirme que les MFC et .NET sont bel et bien de l'objet pur et dur. Du coup, utiliser les MFC en dehors du C++ sous Visual est, je pense, impossible (ou alors, chapeau à celui qui a réussi). Pour .NET, c'est du managé, donc c'est aussi une ABI différente, et qui n'a pas de "passif" : les langages .NET se sont simplement adaptés à l'ABI définie, donc pas de soucis d'intéropérabilité du coup.

Citation:

---

Envoyé par JolyLoic

La preuve, c'est le nombre de gens qui prennent une bibliothèque portable en C++ wrappant une partie de l'OS alors même qu'ils savent bien que la portabilité ne sera jamais utilisée, simplement parce qu'elle offre une API plus agréable d'emploi <...> ou qui développent eux même un wrapper par dessus l'OS, dès qu'il s'agit d'appeler la fonction plus d'une fois <...>

---

Oui et non : il y a trois raisons à ça, et pas forcément la syntaxe plus ou moins agréable.

La première, c'est de rendre des fonctions [quelquechose]-safe alors qu'elles ne le sont pas naturellement, et ceci en évitant d'avoir à chaque fois à appeler plusieurs fonctions (et surtout en évitant de les oublier ! ;)).
Le thread-safe est courant, bien sûr, mais parfois c'est le rendre process-safe qui est nécessaire, ou une protection quelconque spécifique.
Cette raison d'encapsuler est très saine : on groupe des fonctions qui sont des primitives du système afin d'effectuer des opérations un peu plus complexe, tout en gardant une interface simple au niveau du système (fonctions basiques et unitaires, donc).

La seconde, c'est la portabilité entre plusieurs OS. Certes, il existe de nombreuses librairies permettant de telles abstractions, mais elles ne sont pas toujours adaptées au besoin : elles peuvent être trop lourdes, trop light, ne pas supporter la plate-forme désirée, etc.
Cette raison est également très saine, que l'on refasse ou que l'on utilise peu importe. On abstrait une dépendance à un système d'exploitation (ou à un processeur) via les possibilités du langage. On peut aussi le faire en C, c'est vrai, mais on arrive souvent devant le problème non négligeable des surcharges.

La dernière, c'est de ne pas avoir réussi à comprendre qu'une fonction C peut être appelée depuis du C++, et surtout de croire que si ce n'est pas une classe, c'est forcément "mal" et "pas C++".
Cette raison là est au contraire malsaine, et entretient la guéguerre entre les deux langages. Wrapper un truc aussi primaire et autonome que "GetTickCount()" (sous Windows) dans une classe qui ne contient que cette méthode, c'est franchement débile. Rigole pas, j'ai hélas déjà vu ça dans du code.

Citation:

---

Envoyé par fcharton

C'est la réalité du métier, le C++, c'est souvent employé sur de gros programmes, gérés par des équipes importantes, et ayant de longues durées de vie. Ce sont des grosses machines, qui tournent lentement.

---

Tout à fait. 10 à 25 ans en moyenne... A mes débuts, il y a 10 ans, utiliser la STL était synonyme de galère en chaîne, de performances minables, d'inflation de la taille des binaires et de bugs à tout va. J'ai passé plus de six mois à péter du code STL posant problème (STL pas si standard que ça, support des templates aléatoire, etc.) vers du C (ou même du C++) "à la main", mais qui offrait les performances attendues.

Dix ans plus tard, je fais (presque) le contraire : les compilateurs ont évolué, les anciennes plate-formes deviennent obsolètes (et LE compilateur de la plate-forme avec au passage), et les choses évoluent au fur et à mesure de la reprise du code. Sauf qu'il faut continuer à expliquer aux dévs débutants que des choses comme les maps indexées par des strings, ou des réallocation de mémoire en plein milieu d'un code temps réel, c'est mal... ;)

Citation:

---

Envoyé par Mac LAK

La première, c'est de rendre des fonctions [quelquechose]-safe alors qu'elles ne le sont pas naturellement, et ceci en évitant d'avoir à chaque fois à appeler plusieurs fonctions (et surtout en évitant de les oublier ! ).
Le thread-safe est courant, bien sûr, mais parfois c'est le rendre process-safe qui est nécessaire, ou une protection quelconque spécifique.

---

Le memory-leak-safe (et sa version plus luxueuse le exception-safe, qui vient quasiment pour le même prix) est pour moi la principale raison de wrapping. Toutes ces fonctions qui allouent des buffers de caractères, des handles, du lock/unlock en deux fonctions séparées, ça me met mal à l'aise.

Citation:

---

Envoyé par Mac LAK

Cette raison là est au contraire malsaine, et entretient la guéguerre entre les deux langages. Wrapper un truc aussi primaire et autonome que "GetTickCount()" (sous Windows) dans une classe qui ne contient que cette méthode, c'est franchement débile. Rigole pas, j'ai hélas déjà vu ça dans du code.

---

Pour ma part, je plaide coupable d'avoir wrappé QueryPerformanceCounter, et de deux manières en plus... Et si c'était à refaire, je le referais, et je pense que j'aurais le même raisonnement pour GetTickCount. Pourquoi ? Car mon wrapping apportait des fonctionnalités supplémentaires. Dans un cas, juste la mémoire de l'instant de démarrage de l'horloge, et l'affichage du résultat dans une unité gérable par un humain : la seconde.

Code:

---

1 2 3

Clock clk; f(); cout << "f a duré " << clk.run() << "s" << endl;

---

Dans un autre cas, la même chose, plus la gestion de pauses où l'on arrête de mesurer le temps.

Code:

---

1 2 3 4 5 6 7 8

Clock clk; f(); clk.pause(); dumpDebugData(); clk.resume(); g(); cout << "f+g ont duré " << clk.run() << "s" << endl;

---

Citation:

---

Envoyé par JolyLoic

Toutes ces fonctions qui allouent des buffers de caractères, des handles, du lock/unlock en deux fonctions séparées, ça me met mal à l'aise.

---

Il est parfois nécessaire de laisser deux fonctions pour ça à cause de traitement très longs et/ou interprocess : en général, je les appelle "StartXXXX" / "StopXXXX" ou "BeginXXXX" / "EndXXXX" en fonction du contexte. Toutefois, c'est sûr que pour protéger une fonction par mutex, une classe d'autolock par portée est préférable.

Citation:

---

Envoyé par JolyLoic

Pour ma part, je plaide coupable d'avoir wrappé QueryPerformanceCounter, et de deux manières en plus... Et si c'était à refaire, je le referais, et je pense que j'aurais le même raisonnement pour GetTickCount. Pourquoi ? Car mon wrapping apportait des fonctionnalités supplémentaires. Dans un cas, juste la mémoire de l'instant de démarrage de l'horloge, et l'affichage du résultat dans une unité gérable par un humain : la seconde.

---

Pour QPC, c'est très différent, et je l'ai fait aussi. Pourquoi ? Parce que déjà, il faut utiliser QueryPerformanceFrequency avant, en stocker la valeur, et que l'unité "finale" (liée à la résolution du timer) ne peut pas être connue à l'avance, contrairement à GetTickCount, ou autres gettimeofday, par exemple. Donc, là, le besoin d'une classe rentre dans le premier cas que j'énonçais, et tu n'es coupable de rien ! ;)
D'ailleurs, ma classe Delphi gérant ça est même encore pire : elle adapte l'unité d'affichage en fonction de la durée écoulée, de la nanoseconde jusqu'à l'heure... :mouarf:

Moi, je te parle d'un goret (pas d'autre mot) qui, à quelques lignes près, a pondu cette classe :

Code:

---

1 2 3 4 5 6 7 8

class TickCount { public: TickCount() {} ; virtual ~TickCount() {} ;   virtual unsigned long int GetTick() { return GetTickCount() ; }   } ;

---

Tu remarqueras l'absence de "static" gaiement remplacé par du "virtual", l'inutilité de la classe vu le manque de valeur ajoutée (pas même un << ou >> redéfini...), pas même un namespace qui pourrait justifier un truc comme ça et autres joyeusetés du même ordre. Promis, je n'invente pas, j'ai réellement vu ce ... machin, on va dire, dans un projet.

Citation:

---

Envoyé par Mac LAK

Moi, je te parle d'un goret (pas d'autre mot) qui, à quelques lignes près, a pondu cette classe :

Code:

---

1 2 3 4 5 6 7 8

class TickCount { public: TickCount() {} ; virtual ~TickCount() {} ;   virtual unsigned long int GetTick() { return GetTickCount() ; }   } ;

---

---

Il aurait au moins pu mettre ça dans une struct, ça aurait déjà eu plus de gueule :mrgreen:

Citation:

---

Envoyé par fcharton

Je ne crois pas... Il y a une évolution, lente, comme tout ce qui se fait dans le monde réel, mais bien réelle, de la façon dont on programme en entreprise.

Mais c'est lent, la STL commence à devenir la norme. Boost, c'est encore le futur, mais on commence à voir des templates utilisés de façon sérieuse.

---

Moi j'ai l'impression que boost commence à entrer en force dans de nombreux projets.. en tout cas open sources puisque j'ai pu regarder leur codes. Pour les trucs fermés spécifiques aux entreprises, là j'en sais trop rien. En top des charts, je dirais boost *_ptr, lexicalcast, noncopyable (:mrgreen:), regex. A vrai dire, j'ai bien l'impression que ces librairies sont utilisées de manière plus fréquente que ce qu'on trouve dans <algorithm>.

Citation:

---

Envoyé par metagoto

Moi j'ai l'impression que boost commence a entrer en force dans de nombreux projets.. en tout cas open sources puisque j'ai pu regarder leur codes. Pour les trucs fermés spécifiques aux entreprise, là j'en sais trop rien.

---

J'ai l'impression que l'open source est toujours plus "moderniste" que le monde de l'entreprise. J'y vois trois raisons :

- les projets sont plus récents (un projet open source qui à 5 ans, c'est déjà un truc bien établi, un logiciel d'entreprise du même âge est très très jeune)
- les développeurs sont généralement plus jeunes (donc plus friands de modernité)
- les programmes open source servent souvent de vitrine à leurs auteurs, il y a une forte tendance à privilégier des approches techniques, modernes, voire hasardeuses, l'entreprise, à l'inverse, favorise l'ancien et l'éprouvé

Ce que j'observe, néanmoins, c'est qu'en entretien, on te regarde moins avec de grands yeux quand tu dis boost qu'il y a deux ou trois ans (dans ces entretiens je suis du coté du recruteur, et je vois souvent des gens ayant déjà une expérience).

Citation:

---

Envoyé par metagoto

En top des charts, je dirais boost *_ptr, lexicalcast, noncopyable (:mrgreen:), regex. A vrai dire, j'ai bien l'impression que ces librairies sont utilisées de manière plus fréquente que ce qu'on trouve dans <algorithm>.

---

Pour regex, ca s'explique par le fait qu'il s'agit d'une technique ancienne, bien connue, mais pour laquelle il n'y avait pas de solution "de base". Boost remplit ce vide. Pour les pointeurs, boost comble une lacune de la STL.

Maintenant, pour <algorithm>, je ne suis pas d'accord. Les find(), copy(), fill() remove() et sort(), et merge() sont assez communément utilisés (parce qu'ils répondent à des besoins courants).

Les algorithmes plus "génériques" (transform et autres qui prennent des foncteurs en paramètres) le sont moins.

On pourrait dire la même chose des conteneurs, d'ailleurs. Les vecteurs et les string sont passés dans la pratique. Les map et les set sont utilisés (mais presque toujours de travers), les list, les deques, et les multi*, très peu.

En fait, et ca nous ramène au début de cette discussion, partout ou la STL ou Boost apportent une solution efficace à un problème classique (tris, recherches, copies, tableaux associatif, expressions régulières), ils sont utilisés.

Partout où ils introduisent une nouvelle façon d'aborder un problème (inner_product, partial_sum), ils mettent plus de temps.

Francois

Citation:

---

Envoyé par fcharton

J'ai l'impression que l'open source est toujours plus "moderniste" que le monde de l'entreprise. J'y vois trois raisons

---

Je ne sais pas trop ce que tu entends par "moderniste"... peut-être le fait d'assimiler des notions qui ont montré leur efficacité récemment?
De toutes façons, il n'y a aucune raison de couper un cheveux en quatre ici, la raison est vraiment très simple: la collaboration est plus efficace que la concurrence.

J'ai mis le mot entre guillemets parce que je n'en trouvais pas de meilleur. Par moderniste, je voulais dire sensible à la nouveauté. Le monde de l'open source intègre rapidement les nouveautés techniques, celui de l'entreprise avance plus prudemment, et plus lentement.

Je ne crois pas que l'un ait raison et que l'autre ait tort. En se précipitant sur toutes les nouveautés techniques, on progresse plus vite, mais on essuie les plâtres (il y a des idées à la mode qui se révèlent mauvaises, en informatique comme ailleurs). En attendant trop longtemps, on limite les risques, mais aussi la croissance.

Francois

Salut!

Citation:

---

Envoyé par Nogane

programmeur "C with class"

---

Je me considère malheureusement comme ça, et j'avoue que c'est surement la faute des profs, le problème c'est peut être aussi les compilateur qui acceptent le mélange des 2 sans problème.

J'aimerai beaucoup savoir réellement coder en C++, mais ça simplifie pas mal la programmation (pas le programme hein) d'utiliser du C dans le code, plutôt que d'aller chercher et de comprendre le fonctionnement d'un moyen de le faire en C. BOOST par exemple, c'est tellement vaste que je ne sait même pas par ou l'aborder, je ne sait même pas si ça me sera réellement profitable... surement mais bon...

peut être y aurait il moyen de faire une FAQ "du C au C++" montrant pour des problèmes récurant comment faire en C++ l'équivalent d'un bout de code en C.
Par exemple, sur mon dernier projet en "C with class" je me suis décidé a utiliser les fonctions/méthodes C++ pour la gestion des fichiers plutôt que les fonctions C que j'utilisai jusque maintenant. le problème c'est que ça m'a tout fait planter, alors pour éviter de perdre du temps a chercher, (je suis feignant, c'est ma faute) ben j'ai finalement utilisé... le C... :(

bref, le C++ , quand on connait déjà le C, il faudrait l'aborder comme un nouveau langage, mais je pense que personne le fait, personnellement j'essaye de migrer petit a petit, mais c'est pas facile sans personne pour me dire "tu devrais utiliser ça plutôt que ça, ça te simplifierai la vie..."

Citation:

---

Envoyé par bebaijhi

... mais c'est pas facile sans personne pour me dire "tu devrais utiliser ça plutôt que ça, ça te simplifierai la vie..."

---

Je penses que tout le problème est là... L'apprendre comme un nouveau langage, c'est peut-être (même très certainement) une bonne solution. Mais pas facile lorsque ça se ressemble autant.

Le problème est en soit que l'enseignement s'arrête généralement au C with Classes...
Honnêtement, pour boost, je suis a peu près dans le même cas que toi. J'essaye de regarder si il y a des trucs qui pourrait m'intéresser dedans au cas part cas, et si oui, je m'y penche sérieusement. Il y a aussi la STL, et c'est d'ailleurs prioritaire à mon avis, que tu dois apprendre à maîtriser.

Malheureusement, si tu veux bien apprendre, il y a un moment ou tu dois prendre ton temps : dit toi que faire du "vrai" C++, c'est du temps de gagner en cas de mis-à-jour de ton programme.

Citation:

---

Envoyé par fcharton

J'ai l'impression que l'open source est toujours plus "moderniste" que le monde de l'entreprise. J'y vois trois raisons :

---

Ah bon? J'ai l'impression contraire. Que par l'héritage et l'habitude la grande majorité des projets open source reste ancré dans la tradition C.

@ lavock : t'as changé d'avis au final ? :p. (sur l'apprentissage).

Quand a boost, j'étais comme ça aussi plus 'jeune' (comprendre y'a quelques mois xD) finalement faut commencez par un bout, pas un truc énorme non plus (genre boost.spirit), si je me souviens bien j'avais commencé par boost.signal par besoin, (je compte pas smart_ptr que j'utilisais déjà) puis de fil en aiguille je me suis intéressé un peu à toute les parties assez rapidement assimilée au final. (je compte pas les trucs spécifiques comme gil ou python etc).
Mais je rejoins lavock la priorité c'est la SL.

Citation:

---

Envoyé par Goten

Ah bon? J'ai l'impression contraire. Que par l'héritage et l'habitude la grande majorité des projets open source reste ancré dans la tradition C.

---

Les projets en C sont ancrés dans la tradition C (et c'est un peu logique).

Ceux en C++ ont tendance à utiliser des versions modernes du langage.

Francois

Ouai vu comme ça... (fluxbox notamment, kde bien évidemment). Mais les projets opensource en C++ sont pas légion.


(on est un peu hors sujet :p )

Citation:

---

Envoyé par Goten

@ lavock : t'as changé d'avis au final ? :p. (sur l'apprentissage).

---

Non pas vraiment... C'est un idéal (abstrait). Vaut mieux éviter les ruptures brutales pédagogiquement parlant...

Si au final se sont deux langages distinct, au début non. Je dirai qu'une approche serai d'abord de faire du C with Classes; puis une fois assimilé, coupé le C(ordon). Et pas, comme souvent hélas, trois fois hélas, s'arrêter avant.

Citation:

---

Envoyé par Lavock

Si au final se sont deux langages distinct, au début non. Je dirai qu'une approche serai d'abord de faire du C with Classes; puis une fois assimilé, coupé le C(ordon). Et pas, comme souvent hélas, trois fois hélas, s'arrêter avant.

---

Je trouve, au contraire, que, si l'apprentissage du C++ doit (pour une question d'organisation des cours) arriver après C, la rupture doit être brutale, du genre "vous avez appris le C, c'est très bien... Pour ce cours ci, vous oubliez tout parce que, bien que le terme C apparaisse dans C++, il s'agit d'un langage tout à fait différent".

L'idée étant que, selon les base OO déjà abordées, on apprenne soit le C++ sous sa forme purement "procédurale" (en utilisant malgré tout la SL et la STL) soit sous sa forme OO (en parlant directement des classes et de ce quelles représentent), et que l'on n'aborde le "tronc commun" existant entre C et C++ (je pense, essentiellement, au pointeur) que lorsque c'est effectivement nécessaire et sous une forme proche de " rappelez vous des pointeurs en C" (par exemple)

Je préférerais en effet très largement voir un prof conseiller, en C++, l'utilisation d'une structure proche de

Code:

---

1 2 3 4 5

struct MaStruct { Type1 truc; std::vector<Type2> machin; };

---

que de voir un prof conseiller l'utilisation d'une classe proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class MaClass { private: char * name_; Type1 * tabTruc; public: MaClass(char const * n; Type1* const t); ~MaClass(); /* quelques méthodes, dont principalement des mutateurs et des   * accesseurs   */ };

---

comme c'est (trop :question:) souvent le cas :P

Citation:

---

Envoyé par Goten

Quand a boost, j'étais comme ça aussi plus 'jeune' (comprendre y'a quelques mois xD) finalement faut commencez par un bout, pas un truc énorme non plus (genre boost.spirit), si je me souviens bien j'avais commencé par boost.signal par besoin, (je compte pas smart_ptr que j'utilisais déjà) puis de fil en aiguille je me suis intéressé un peu à toute les parties assez rapidement assimilée au final. (je compte pas les trucs spécifiques comme gil ou python etc).

---

L'intérêt de boost, je trouve, c'est qu'on est rapidement obligé de bosser son C++ avant de pouvoir utiliser certaines de ces librairies, tout simplement parce que sinon on ne comprend rien de ce qu'on fait et comment ça marche.
Les libs inclues dans boost sont assez disparates, mais certains idiomes et techniques reviennent souvent. Mieux vaut les étudier et travailler sereinement avant de trop vouloir faire le mariole avec telle ou telle librairie.

Citation:

---

Envoyé par metagoto

L'intérêt de boost, je trouve, c'est qu'on est rapidement obligé de bosser son C++ avant de pouvoir utiliser certaines de ces librairies, tout simplement parce que sinon on ne comprend rien de ce qu'on fait et comment ça marche.
Les libs inclues dans boost sont assez disparates, mais certains idiomes et techniques reviennent souvent. Mieux vaut les étudier et travailler sereinement avant de trop vouloir faire le mariole avec telle ou telle librairie.

---

J'aurais tendance à dire le contraire... Faut pas être Alexandrescu pour pouvoir pleinement profiter de boost. En fait boost est là pour simplifier les choses, pas pour les rendre plus compliquées qu'elles ne le sont déjà.

Faut pas être super calé en parsing pour utiliser boost.regex ou boost.spirit, comme faut pas être super calé en allocateurs pour utiliser boost.smart_ptr. Tout comme il ne faut pas absolument connaître l'endianess pour utiliser boost.serialization... Tout comme il ne faut absolument pas savoir recréer Loki pour utiliser boost tout court...

Chacun son boulot, imo, ceux qui font de la metaprog pour aider les developpeurs métiers, et les développeurs métiers...

Citation:

---

Envoyé par JulienDuSud

Faut pas être super calé en parsing pour utiliser boost.regex ou boost.spirit, comme faut pas être super calé en allocateurs pour utiliser boost.smart_ptr. Tout comme il ne faut pas absolument connaître l'endianess pour utiliser boost.serialization... Tout comme il ne faut absolument pas savoir recréer Loki pour utiliser boost tout court...

Chacun son boulot, imo, ceux qui font de la metaprog pour aider les developpeurs métiers, et les développeurs métiers...

---

C'est pas faux, car c'est effectivement le but d'une librairie.
Mais je persiste à dire que sans un certain bagage, il ne faut pas s'étonner qu'on ne capte rien à certains composants de boost (à moins que je sois le seul dans ce cas là?). Par exemple Boost.MPL : c'est simple, y a tout dans la doc. Il n'empêche que ça demande, je trouve, une certaine maturité et connaissance du C++ pour l'utiliser efficacement. On ne peut pas se lancer dans ce genre de lib sans avoir travaillé un minimum en amont.

Citation:

---

Envoyé par JulienDuSud

Faut pas être super calé en parsing pour utiliser boost.regex ou boost.spirit, comme faut pas être super calé en allocateurs pour utiliser boost.smart_ptr. Tout comme il ne faut pas absolument connaître l'endianess pour utiliser boost.serialization... Tout comme il ne faut absolument pas savoir recréer Loki pour utiliser boost tout court...

---

Je pense le contraire... Utiliser des outils pointus (les regex ou les parser c'est très pointu) sans savoir comment ils fonctionnent, c'est aller droit dans le mur. D'abord, parce que la puissance de ces outils a un coût en terme de vitesse d'exécution. Ensuite, parce que pour bien utiliser un outil, il faut au minimum bien connaitre le problème qu'il résout.

C'est déjà vrai de la STL. Il suffit de voir le nombre de cas où l'on arrive à accélérer un programme juste en enlevant les map mal à propos et en les remplaçant par des vector, ou en ajoutant ici et là des set, ou en s'arrangeant pour que l'on n'appelle pas sort() trois fois de suite sur un tableau trié (ou qu'on se jette sur un sort() dès que deux malheureux enregistrements ne sont pas ordonnés, ou qu'on utilise des tris stables quand on n'en a pas besoin).

Et je ne parle même pas des malheureux qui essaient de lire 200Mo à coup de getline(), ou qui se jettent sur boost date time dès qu'un programme utilise des dates (même s'il ne s'agit que de les lire et les récrire).

Au final, ca produit des programmes qui tournent très lentement (mais c'est sur, ils sont simples et maintenables...).

Et ca nous ramène une fois de plus à la question de l'apprentissage du C. Il me semble qu'on utilise le C++ (à la place de langages interprétés plus simples) quand on veut écrire des programmes complexes mais rapides.

En C elle était obtenue grace à des instructions qui se traduisaient en un petit nombre d'instructions machine. Il est possible de faire la même chose en C++, mais il faut savoir de quoi on parle, et la connaissance de son "héritage C" est au coeur de cette compréhension.

Peut être qu'au fond la bonne question serait : peut on bien programmer en C++ sans connaitre le C?

Moi je dirais non.

Francois

Citation:

---

Envoyé par JulienDuSud

J'aurais tendance à dire le contraire... Faut pas être Alexandrescu pour pouvoir pleinement profiter de boost. En fait boost est là pour simplifier les choses, pas pour les rendre plus compliquées qu'elles ne le sont déjà.

Faut pas être super calé en parsing pour utiliser boost.regex ou boost.spirit, comme faut pas être super calé en allocateurs pour utiliser boost.smart_ptr. Tout comme il ne faut pas absolument connaître l'endianess pour utiliser boost.serialization... Tout comme il ne faut absolument pas savoir recréer Loki pour utiliser boost tout court...

Chacun son boulot, imo, ceux qui font de la metaprog pour aider les developpeurs métiers, et les développeurs métiers...

---

Tout à fait. Et justement les techniques moderne (traits, policies etc) décrite par Alexandrescu sont des techniques orienté conception de bibliothèques (et pas librairie :p) afin de faciliter la vie de l'end user.
Certes comprendre ce genre de techniques est un bonus au final quand on utilise boost, mais de prime abord je pense que c'est pas une obligation de les comprendre.

Citation:

---

Envoyé par fcharton

<snip>
En C elle était obtenue grace à des instructions qui se traduisaient en un petit nombre d'instructions machine. Il est possible de faire la même chose en C++, mais il faut savoir de quoi on parle, et la connaissance de son "héritage C" est au coeur de cette compréhension.

Peut être qu'au fond la bonne question serait : peut on bien programmer en C++ sans connaitre le C?

Moi je dirais non.

Francois

---

En fait, cela dépend des priorités que tu places pour ton programmes...

Dans l'ordre, mes priorités seraient:

1. que le code soit facile à lire et à maintenir
2. que le programme fasse ce que l'on attend de lui
3. que le programme soit rapide

Avec cet ordre de priorités la connaissance du C afin d'apporter des optimisations utiles devient... utile mais secondaire, dirais-je.

Dans certains secteurs, on peut envisager des priorités différentes, comme

1. que le programme fasse ce que l'on attend de lui
2. que le programme soit rapide (un programme rapide qui ne fait pas ce qu'on attend de lui n'ayant aucun intérêt :D)
3. que le code soit facile à lire et à maintenir

Dans de tels cas, on pourrait envisager le tronc commun C/C++ comme une possibilité d'améliorer les performances, et donc estimer que la connaissance du C devient primordiales.

Cependant, avant d'envisager d'utiliser C dans les parties "sensibles", j'aurais encore tendance à insister une fois de plus sur la nécessité de s'assurer d'utiliser... le meilleur algorithme possible et donc de n'utiliser C qu'une fois que l'on a *réellement* la certitude que l'algorithme utilisé est le meilleur, ainsi que de s'assurer du fait que l'on n'essaye pas d'optimiser quelque chose qui... n'en vaudrait pas la peine ;)

Bien sur, cette approche n'engage que moi (mais j'y adhère :D) et je laisse tout le monde libre d'avoir son opinion sur le sujet :D

Citation:

---

Envoyé par fcharton

Peut être qu'au fond la bonne question serait : peut on bien programmer en C++ sans connaitre le C?

---

De mon point de vu, cette question n'a pas de réponse absolue.

D'une part, ça dépend énormément du domaine et du profil recherché.
D'autre part ça dépend énormément de ce que tu appelles "bien programmer" et "connaitre le C" (comme l'a fait remarquer il y a un monde entre savoir utiliser correctement une API en C et être capable de l'écrire).

Je me permet de réagir sur ce thème (même si je crois en avoir parlé l'année dernière sur un sujet similaire), puisque étant en deuxième année d'une école d'ingénieur, je peux en témoigner, sachant que ma vision est un peu différente, l'objectif n'est pas de convaincre des personnes qui programme depuis des lustres, mais en l'occurrence des étudiants qui programment depuis peu (lorsque je suis rentré en première année, on était peu à avoir déjà programmer).

Je passerai sur les élèves qui me disent que "de toute façon, autant uniquement apprendre le C et ne pas se faire chier sur d'autres langages puisque, de toute façon, en étant dans une école d'ingénieur ils sont là pour devenir des manageurs et non des pisseurs de code".

Histoire que vous ayez une vision de la "courbe" d'apprentissage de la programmation, voici comment cela se passe dans notre école (ingénieur, axé informatique), j'imagine que c'est un peu le même cas dans les autres :

Première année : Algorithmie, C
Deuxième année : Algorithmie, C++
Troisième année : Java, (C# je crois)

Je suis actuellement en L2, et les cours de C++ débutent au deuxième semestre, donc je ne peux pas témoigner sur la qualité des cours, mais un cours de programmation se divise principalement en trois "sections" :

- Les cours en amphithéâtre. Comme l'a souligné une personne plus haut, j'ai aussi cette sensation que les profs se considèrent plutôt comme "prof d'algorithmie", puisque, en fait, les cours ne portent pas le nom de "Cours de C" mais "Cours d'algorithmie". Concrètement, le professeur utilise un "langage algorithmique" plutôt que du C, sous prétexte que ce langage algorithmique a l'avantage de ne pas être dépendant d'une syntaxe. En pratique, ce langage algorithmique consiste à remplacer float, int, double... par réel, entier, if, else, while par SI, SINON, TANT QUE...

- Les "TD", ou "je code sur ma feuille". Pour moi, mais quelqu'un pourra peut-être me contredire, je considère ceci comme une ineptie. Quel est l'intérêt de "coder" sur une feuille ? De par ce que j'ai pu voir parmi les élèves, ceci à pour unique conséquence de dégouter une partie des élèves de la programmation.

- Les "TP", ou "je copie colle les sujets de TD, mais vous faites les exos sur l'ordinateur maintenant".

Voilà rapidement pour l'enseignement de la programmation en école d'ingénieur.

Concernant à présent le débat C et C++, j'ai bien peur que le même schéma se passe dans notre école. On nous présente, au tout début de la première année, les différents langages, en nous expliquant que le C++ est une évolution de C, une sorte "d'extension". Bref, dès le premier cours "d'algorithmie", il est rentré dans la tête des élèves que le C++ est une extension du C, comment voulez-vous que ceci change ? Résultat, lorsque je dis à mes amis que j'ai commencé par le C++, on me rétorque que je suis fou et on me demande l'intérêt.

Comme ceci a été souligné très justement par plusieurs personnes, il est inconcevable, à fortiori dans mon cas ou les gens ont, au maximum, 1 an de programmation dans le dos, de leur parler RAII ou de concepts compliqués dont il ne verrai pas l'intérêt.

J'ai pas mal observé mes camarades durant les cours de C, et je me suis aperçu que ce sont systématiquement les mêmes remarques qui reviennent : "putain, j'ai un problème avec ce pointeur", ou "comment je fais pour avoir un tableau dynamique sans avoir à faire des realloc bien chiants"... Et c'est clairement là qu'on peut convaincre les gens que les langages sont différents, justement en leur présentant les solutions à leur problème (à savoir std::vector pour les tableaux dynamiques, les pointeurs intelligents, la classe string...). La plupart du temps, les gens me répondent : "ah ouais, ça c'est pas mal, t'aurais pas un livre pour apprendre le C++ ?".

L'objectif principal est de leur faire prendre conscience qu'il existe des solutions en C++, qui soient propres, efficaces et simples à utiliser.

Comme je l'ai dit plus haut, je n'ai pas eu l'occasion d'avoir eu les cours de C++ encore, mais j'ai pu lire les slides du prof et, de mémoire, il traite effectivement d'abord la notion de POO, et passe très rapidement à la fin sur les templates, la STL... et c'est bien dommage. La POO, ils n'en verront peut-être pas "immédiatement" l'utilité, alors que std::vector, std::string, ça fera directement tilt dans leur esprit : il y a une solution à ce à quoi ils ont galéré durant des mois en C.

Même si je n'ai aps le droit vis-à-vis de l'école de mettre en ligne les slides du prof de C++, voici quand même le plan, histoire de vous donner une idée de la manière dont le C++ est enseigné dans une école d'ingénieur :

EDIT : je viens de m'apercevoir que des slides plus récents (et beaucoup plus beaux) sont en fait en lignes sur le réseau de l'école. J'ai regardé rapidement, et c'est quand même beaucoup mieux. Il cite même quelques exemples du moteur 3D Ogre pour montrer comment il est implémenté, avec de jolis diagrammes UML. C'est vraiment bien foutu, par contre les différents thèmes sont organisés de la même façon que ce que j'écris juste en dessous. En tout cas de très gros progrès ont été faits sur ce cours de C++.

Cours 1 : Introduction des entrées/sorties, référence, surcharge de fonctions, manière d'utiliser les fonctions C en C++, fonctions inline, allocations dynamiques avec new/delete à la place de malloc/free. Et, en prime, un magnifique slide indiquant que le C++ est un sur-ensemble de C.

Cours 2 : limitations des structures du C => présentation des classes : sécurisation des accès avec public, private, protected ; méthodes ; variables membres ; constructeur ; destructeur ; surcharge des opérateurs ; exemple de création d'une classe nombreComplexe.


Cours 3 : héritage & composition, liste d'initialisation (ça c'est un bon point déjà :)), polymorphisme, classes abstraites.


Cours 4 : exceptions, exceptions dans le constructeur, namespace

Cours 5 : template, présentation de la STL, les fichiers en C++.


Je ne suis pas très clair dans ce que je veux dire, mais je pense effectivement que le problème vient directement de l'enseignement, ou le C est systématiquement enseigné en premier, ou le C++ présenté comme un subset du C, et lorsque le C++ est enseigné, c'est plus le côté "POO" qui est mis en avant, plutôt que la SL...


PS : Je tiens à préciser, au cas où des admins de l'école tourneraient par ici, que mon objectif n'est pas de dénigrer l'école où je suis et où je m'y sens bien, mais juste de pointer du doigt certaines faiblesses dans la manière d'enseigner la programmation et qui contribuent à faire de très mauvais programmeurs C++, même si beaucoup d'élèves argueront que de toute façon ils ne souhaitent pas devenir programmeur.

Citation:

---

Envoyé par Bakura

- Les "TD", ou "je code sur ma feuille". Pour moi, mais quelqu'un pourra peut-être me contredire, je considère ceci comme une ineptie. Quel est l'intérêt de "coder" sur une feuille ? De par ce que j'ai pu voir parmi les élèves, ceci à pour unique conséquence de dégouter une partie des élèves de la programmation.

---

Pour ma part, je vois au moins un avantage à "coder sur une feuille", c'est d'éviter que les élèves se reposent entièrement sur le compilateur pour détecter leurs erreurs et qu'ils considèrent que "ça compile" est un synonyme de "ça marche".
Sur papier tu ne peux pas te reposer sur une programmation à base d'essais erreurs (i.e. le code ne fait pas ce que je veux, je modifie le code jusqu'à ce qu'il compile, je réexécute, et si le code ne fait pas ce que je veux, je boucle), ça oblige les élèves à apprendre la rigueur nécessaire à une bonne programmation (bon après ça a quand même ses limites les TD's papier, je n'en fait pas l'apologie mais ça permet de prendre un peu de "distance" vis-à-vis du code)

On est d'accord seulement.. écrire du C++ à la main.. c'est pain in the as* sérieux. Autant ok de l'algorithmie sur papier c'est parfait (c'est fait pour :p), du pseudocode etc.
Mais du C++ ?

le temps d'écrire std::vector<int> foo; ... non sérieux c'est une ineptie, y'a pas d'autre mot.

Citation:

---

Envoyé par Goten

On est d'accord seulement.. écrire du C++ à la main.. c'est pain in the as* sérieux. Autant ok de l'algorithmie sur papier c'est parfait (c'est fait pour :p), du pseudocode etc.
Mais du C++ ?

le temps d'écrire std::vector<int> foo; ... non sérieux c'est une ineptie, y'a pas d'autre mot.

---

Je n'ai pas dit que l'on codait du C ou du C++ sur du papier. On code un "pseudo-langage", mais ce pseudo-langage est tellement proche du C qu'en fait, ça revient un peu au même. Mais dans l'esprit, on ne nous fait pas "coder du C sur papier". Légère nuance :aie:.

Citation:

---

Envoyé par koala01

Dans l'ordre, mes priorités seraient:

1. que le code soit facile à lire et à maintenir
2. que le programme fasse ce que l'on attend de lui
3. que le programme soit rapide

---

J'avoue avoir beaucoup de mal avec la viabilité de cette approche dans un cadre professionnel... Le respect des specs est forcément la première priorité (imagine toi disant à ton responsable : "non ça ne marche pas correctement, mais ca sera drolement facile à maintenir...")

Ensuite, la rapidité fait généralement partie des specs, ou du moins partiellement. Si la spec demande un recalcul automatique (par exemple qu'un tableau se mette à jour quand tu coches une case, ou quand tu glisses un élément), tu peux faire attendre ton utilisateur 1/2 seconde, éventuellement 2avec un sablier, mais certainement pas 15. Si ton programme test qui fonctionne sur une base de 1000 enregistrement met plusieurs secondes à faire un calcul, il est clair qu'il ne saura rien faire de la vraie base d'un million d'enregistrements sur lequel il doit fonctionner... Pour moi, les specs ont toujours un aspect vitesse (et volumétrie).

Et, personnellement, je remarque que, quand on présente un logiciel à un client, on est presque sur qu'on va conclure une vente quand il commence à dire : ça calcule très vite...

Citation:

---

Envoyé par koala01

Cependant, avant d'envisager d'utiliser C dans les parties "sensibles", j'aurais encore tendance à insister une fois de plus sur la nécessité de s'assurer d'utiliser... le meilleur algorithme possible et donc de n'utiliser C qu'une fois que l'on a *réellement* la certitude que l'algorithme utilisé est le meilleur, ainsi que de s'assurer du fait que l'on n'essaye pas d'optimiser quelque chose qui... n'en vaudrait pas la peine ;)

---

En fait, je ne recommande pas forcément d'utiliser le C, mais je pense qu'il faut savoir pourquoi il est rapide, pour éventuellement utiliser ces principes pour coder (en C++) les parties cruciales.

D'expérience, le problème est rarement l'algorithme, mais souvent des "opérations cachées" qui coutent affreusement cher. Recopies d'objets, recherches inutiles (par exemple sur une map), tris inutiles.

L'inconvénient d'une certaine présentation du C++ (et d'autres langages de haut niveau) c'est qu'il cache ces aspects à l'utilisateur, du coup, on voit des programmeurs qui sont complètement perdus quand ils se trouvent face au problème. Comprendre l'approche 'bas niveau' du C permet souvent de voir la solution (même si on ne l'implémente pas en C).

Quant à savoir ce qui pose problème, il y a des outils pour cela : les profileurs. A mon avis un profileur c'est au moins aussi important qu'un débugger, et il faut l'utiliser assez tot dans le développement.

Francois

Citation:

---

Envoyé par Bakura

Comme je l'ai dit plus haut, je n'ai pas eu l'occasion d'avoir eu les cours de C++ encore, mais j'ai pu lire les slides du prof et, de mémoire, il traite effectivement d'abord la notion de POO, et passe très rapidement à la fin sur les templates, la STL... et c'est bien dommage. La POO, ils n'en verront peut-être pas "immédiatement" l'utilité, alors que std::vector, std::string, ça fera directement tilt dans leur esprit : il y a une solution à ce à quoi ils ont galéré durant des mois en C.

---

C'est assez typique de l'approche "école d'ingénieur", par opposition à l'approche DUT, ou formation technique.

La formation technique a pour but de te donner une connaissance pratique, directement utilisable. L'école d'ingénieur a pour vocation de t'apprendre à apprendre. Regarde comment on enseigne les maths (en prépa par exemple).

Pour l'algèbre, on commence par te faire ingurgiter les ensembles, les groupes, les anneaux, les idéaux, les algèbres, avec tout ce qu'il peut y avoir de théorie, avant de te parler d'espace vectoriels et de matrices, choses directement utiles.

En analyse, on fait (ou au moins faisait, de mon temps) commencer cela par la topologie. Et pour les probas, on commence par l'intégrale de Lebesgue et les espaces de Hilbert (et là, attachez vos ceintures!).

Et comme si ce n'était pas assez, les meilleurs élèves intègrent des écoles généralistes où le programme tourne autour des espaces fonctionnels, quand ce ne sont pas les variétés différentielles et les distributions...

C'est pareil en physique, et aussi en informatique... Du coup, on t'enseigne davantage la théorie des langages informatiques, que la pratique d'un langage, et C et C++ sont enseignés parce que ce sont de bons objets d'étude (mais on préfère te faire faire du pseudocode).

A mon avis, cette approche marche assez bien. De toutes façons, les élèves de ton école qui ne veulent pas devenir programmeurs ne le deviendront pas, même avec trois ans de cours pratiques. Et ceux comme toi qui veulent le devenir apprendront la pratique dans les livres, sur les forums, ou dans leurs projets perso.

Ce que l'école leur apportera, en revance, ce sont des bases théoriques, et sur le long terme, c'est souvent elles qui font la différence. La formation technique atteint ses limites quand on commence à buter sur des choses un peu théoriques, et c'est là que les écoles font la différence.

Francois

Citation:

---

Envoyé par fcharton

J'avoue avoir beaucoup de mal avec la viabilité de cette approche dans un cadre professionnel... Le respect des specs est forcément la première priorité (imagine toi disant à ton responsable : "non ça ne marche pas correctement, mais ca sera drolement facile à maintenir...")

---

Je vais donc justifier mon approche...

Je suis tout à fait d'accord sur le fait que, au même titre qu'un programme rapide qui ne fait pas ce que l'on attend de lui est inutile, il est tout à fait vrai qu'un code lisible qui ne fait pas ce que l'on attend de lui est tout à fait inutile.

Par contre, lorsque le programme ne fait pas ce que l'on attend de lui (ce peut être "simplement" du à l'inversion, dans une séquence, de deux ou plusieurs appels ;)), tu auras bien plus facile à "mettre la main" sur le problème si tu es confronté à un code lisible que si tu es confronté à un code plus ou moins obfusqué.

Il ne faut pas oublier que le propre d'un code source réside le plus souvent dans le "write once, read ever" et que, si tu passe chaque fois un quart d'heure à te gratter la tête pour essayer de comprendre ce qui est fait, tu va perdre au final bien plus de temps que ce que tu aurais pu perdre si tu avais "directement" pensé à écrire ton code de manière lisible ;)

C'est pourquoi, je reste convaincu que la lisibilité du code a une importance plus grande que le fait d'avoir un code qui fait ce que l'on attend de lui.

Citation:

---

Ensuite, la rapidité fait généralement partie des specs, ou du moins partiellement. Si la spec demande un recalcul automatique (par exemple qu'un tableau se mette à jour quand tu coches une case, ou quand tu glisses un élément), tu peux faire attendre ton utilisateur 1/2 seconde, éventuellement 2avec un sablier, mais certainement pas 15. Si ton programme test qui fonctionne sur une base de 1000 enregistrement met plusieurs secondes à faire un calcul, il est clair qu'il ne saura rien faire de la vraie base d'un million d'enregistrements sur lequel il doit fonctionner... Pour moi, les specs ont toujours un aspect vitesse (et volumétrie).

Et, personnellement, je remarque que, quand on présente un logiciel à un client, on est presque sur qu'on va conclure une vente quand il commence à dire : ça calcule très vite...

---

Je te l'accorde également, mais, s'il fait très vite quelque chose de travers, tu ne sera pas avancé non plus...

C'est pour cela que je mets les priorités dans cet ordre particulier, car, selon moi, on ne peut envisager de rejoindre l'une d'elles qu'en gardant celles que l'on a déjà rejoint:

• Ecrivons un code lisible
• Modifions, en cas de besoin, le code pour qu'il fonctionne correctement, en veillant à le garder lisible (sous entendu: si nous n'y sommes pas arrivé lors de la première mouture du code)
• Modifions en cas de besoin le code pour qu'il fonctionne rapidement, en continuant à faire ce que l'on attend de lui, ET en veillant à le garder lisible

Citation:

---

D'expérience, le problème est rarement l'algorithme, mais souvent des "opérations cachées" qui coutent affreusement cher. Recopies d'objets, recherches inutiles (par exemple sur une map), tris inutiles.

---

Effectivement, j'ai un peu hâtivement résumé la situation à l'algorithme...

Dans ma tête, il semble "logique" que les différents conteneurs utilisent différents algorithmes pour arriver à un résultat similaire (il est, par exemple, impossible d'effectuer une recherche dichotomique sur une liste, ce qui n'empêche nullement d'effectuer une recherche)...

Et donc, je reconnais que l'optimisation de l'algorithme peut régulièrement passer par... le choix d'une structure différente.

Il n'empêche qu'il faut à mon gout commencer à optimiser l'algorithme et les structures avant de vouloir optimiser le code qui met cet algorithme en oeuvre...

Sortir d'une boucle l'appel d'une fonction qui invoque une fonction de tri, ou préférer une valeur entière à une chaine de caractères comme clé de tri / comparaison font partie des optimisations à envisager bien avant de décider d'utiliser l'opérateur de post incrémentation au lieu de l'opérateur de pré incrémentation (par exemple)...

Citation:

---

L'inconvénient d'une certaine présentation du C++ (et d'autres langages de haut niveau) c'est qu'il cache ces aspects à l'utilisateur, du coup, on voit des programmeurs qui sont complètement perdus quand ils se trouvent face au problème. Comprendre l'approche 'bas niveau' du C permet souvent de voir la solution (même si on ne l'implémente pas en C).

---

Je te l'accorde...

Cependant, j'aurais plutôt tendance à dire que, bien plus que le fait de savoir "comment c'est fait en C", ce qui importe, c'est d'avoir une connaissance et une compréhension correcte des mécanismes mis en oeuvre en C++ et, pourquoi pas, des mécanismes internes de la S(T)L...

Cette connaissance des mécanismes internes de la S(T)L te fera, par exemple, préférer l'opérateur [] à la fonction at() lorsque tu travailles avec un std::vector<Type> et que tu sais pertinemment être dans les limites autorisée pour l'index ;)

Citation:

---

Quant à savoir ce qui pose problème, il y a des outils pour cela : les profileurs. A mon avis un profileur c'est au moins aussi important qu'un débugger, et il faut l'utiliser assez tot dans le développement.

---

Encore une fois nous sommes bien d'accord...

Je n'ai d'ailleurs jamais dit qu'il ne fallait pas utiliser un profiler ni veiller à apporter les optimisations nécessaires.

Ce sur quoi je met en garde, c'est sur la tentation d'apporter des optimisations prématurées.

Encore une fois, le choix d'utiliser un sucre syntaxique afin d'améliorer les performances est, à mon sens, une optimisation prématurée si l'on n'a pas la certitude d'avoir optimisé au mieux nos structures et nos algorithmes.

Ce ne sera qu'une fois que nous aurons la certitudes d'utiliser les meilleurs algorithmes avec les meilleurs structures en fonction de nos besoins que nous pourrons envisager de "traquer" les quelques fréquences d'horloges perdues à coup de sucre syntaxique... En veillant à faire en sorte que cela en vaille la peine :P

Salut Koala,

En fait, je crois qu'on est d'accord, je vais juste réagir sur un point.

Citation:

---

Envoyé par koala01

Cependant, j'aurais plutôt tendance à dire que, bien plus que le fait de savoir "comment c'est fait en C", ce qui importe, c'est d'avoir une connaissance et une compréhension correcte des mécanismes mis en oeuvre en C++ et, pourquoi pas, des mécanismes internes de la S(T)L...

---

C'est exactement ce que je disais dans ma première réaction (à l'origine de cet échange). Utiliser une librairie (on parlait de Boost) sans savoir comment elle est faite, ou comprendre le problème qu'elle est censée résoudre, c'est dangereux.

Tu n'as pas besoin de savoir écrire <map> pour l'utiliser, mais il est utile de comprendre pourquoi elle utilise des arbres comme structure interne, et pourquoi la garantie d'une recherche en o(log n) n'est pas équivalent à la même garantie pour les vectors.

Tu n'as pas besoin de savoir écrire l'algorithme de tri utilisé par sort, mais savoir quand utiliser (et surtout ne pas utiliser) un tri stable, ca fait une grosse différence (genre 30%), en dépit d'une complexité égale, et savoir que quand on a un tableau presque ordonné, un tri par insertion va *nettement* plus vite, ca peut changer la vie de ton application.

Enfin, les expressions régulières, il est presque aussi important de savoir s'en passer que de savoir les utiliser.

Ce que j'essaie de dire, c'est que ce type de raisonnement, qui se pose très tot des questions de vitesse, est une approche typique du C. Je me demande simplement si quelqu'un qui n'aurait appris *que* le C++ (ce qui n'est, je crois, le cas de presque aucun des intervenants de ce fil) en serait capable. Je dis cela parce que je remarque que les programmeurs qui n'ont fait que des langages "boite à outils de haut niveau" ont souvent du mal avec ce genre d'approche.

Parce que, si c'était le cas, ca justifierait les cours de C et d'algorithmes de l'école citée précédemment...

Francois

le débat me semble avoir beaucoup changé depuis la question initale.
Ce que je voulais dire, c'est qu'il n'y a pas de magie, du code d'un programmeur débutant restera du code de programmeur débutant, qu'il ait un passif de C ou pas.
Et il est illusoire de penser que si on cache le C aux débutants alors d'un coup ils seront des cracks du C++. Le problème n'est pas la.

J'ai étudié pas mal de langages, LISP ou Prolog, C, C++, Latex, Pascal et Delphi, certains en environnement professionnel. j'ai commencé a travailler avec de l'ActionScript 3 et je me suis vautré en beauté. ce n'est pas a cause de ma connaissance du C++ (ou du C), c'est simplement car je ... débutais, comme tout le monde.

le probleme du C++ c'est plutot la gueguerre avec le C qui fait que pour chaque problème que l'on voit, on blâme le C. mais il faut etre honnete, il faut bien débuter un jour, alors il faut mettre les guerres politiques de coté, ne pas chercher a mettre la faute sur quelqu'un (ou quelque chose en l'occurrence) et juste enseigner comment faire.