Discussion :

[Invité]

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

[Goten]

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 )

[Lavock]

@ 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.

[koala01]

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 :

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

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 :

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

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 ) souvent le cas

[metagoto]

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.

[JulienDuSud]

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...

[metagoto]

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.

[Invité]

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

[Goten]

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.

[koala01]

<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 )
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 ) et je laisse tout le monde libre d'avoir son opinion sur le sujet

[gl]

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).

[Bakura]

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.

[CedricMocquillon]

- 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)

[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.

[Bakura]

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 .

[Invité]

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...

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

[Invité]

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

[koala01]

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.

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

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)...

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

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

[Invité]

Salut Koala,

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

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

[screetch]

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.