Discussion :

[SurferIX]

J'ai toujours trouvé assez débile ces offres d'emploi qui indiquent la connaissance de tel ou tel langage de programmation, même si elles sont majoritaires.

Pour moi, ce qui compte c'est la connaissance pointue de l'algorithmique de quelques éléments de maths et du paradigme de programmation utilisé. Pour quelqu'un qui maitrise ces éléments, l'apprentissage d'un nouveau langage de programmation se compte en peu de semaines avant d'en avoir la maitrise.

Je pas complètement d'accord. Si tu connais le principe des pointeurs et des arbres, tu mettras un temps incomparablement plus long à le faire en C qu'à le faire en Php. Donc la phase d'apprentissage d'un langage est extrêmement importante : quelqu'un qui a développé en C depuis des années et qui ne connait pas certains concepts d'algorithmie est une valeur bien plus sûre que quelqu'un qui connait tous les concepts d'algorithmie et qui n'a jamais développé en C. Ce que tu dis est vrai pour la plupart des langages haut niveau, interprétés : Php, Basic, Python et j'en passe. Mais dans le cas qui nous intéresse, le C et le C++, l'expérience est presque plus importante que la notion de certains algorithmes.

[Invité]

Et bien j'ai toujours dit que je connaissais un peu le C++ et pas bien du tout le C et effectivement j'ai souvent vu des yeux exorbités de mes supérieurs à cette évocation.

J'ai toujours pris les développeurs C pour des gourous et des passionnés courageux. Pour moi C c'est pour les pures et durs

C++ est lui plus fréquent et malgré tout (je sais que ça peut paraître étrange) plus accessible. J'ai l'impression qu'il y a beaucoup plus de documentation en C++ qu'en C.

En même temps je ne suis pas très avancé en C++, je fais juste du Qt et un peu de Vst (en gros je joue surtout avec des tableaux, des pointeurs et du calcul assez simplifié).

Mais je conçois que pour énormément de responsables IT C et C++ c'est presque pareil, surtout depuis Java où Java, C#, C et C++ tout ça est un peu pareil. Alors j'ai du mal à expliquer que je ne connais pas très bien C et encore moins C#, mais plus C++.

Faut-il faire la différence sur le CV ?
Bien à partir du moment ou des responsables IT ou des chefs d'équipe ne font pas la différence entre des fichiers générés et du compilé (si si je vous jure et il est payé le double de moi) à quoi bon leur expliquer C#, C et C++. Comme ils le disent ce ne sont que des nuances.

Ceci dit, excepté avec le framework Vst de Steinberg, je serai incapable de réaliser des applications C++ sans QT ou sans C++ Builder. Donc je devrais peu être indiquer Qt/C++ et C++ Builder sur mon CV. Même avec les MFC de Microsoft je ne saurai plus rien faire aujourd'hui.

Puis-je encore dire que je connais C++ ?

[nikko34]

Ben le C++ n'a pas de framework graphique associé, donc forcément un jour où l'autre, tu vas te retrouver à utiliser des librairies tiers ou les librairies du système.

Idem sous Linux, forcément en C++ tu vas te retrouver à utiliser l'api du système d'exploitation. Et cette api elle est en C. Donc t'as un peu intérêt à connaître.

Après pour le monde industriel, je n'utilise pas forcément que des PCs embarqués avec certaines contraintes, on utilise aussi des applis 100% C++/boost avec quelques contraintes mais qui fonctionnent très bien.

On fait aussi des interfaces graphiques (monitoring etc..) sous linux avec du C++/boost/gtkmm, et ça marche très bien.

Après, je ne travaille pas dans une SSII, l'équipe fait un projet de A à Z et pas juste la partie embarqué par exemple. Mais même pour l'embarqué on a démarré des projets utilisant le C++. Evidemment ya certains templates qui ne marchent pas (merci à une ancienne version de gcc) et on attaque des librairies en C. Mais le RAII est tellement agréable à utiliser...

Après, c'est à la technique d'expliquer aux nouveaux comment ça marche la vie, le C, le C++. Si on ne le fait pas.. ben là c'est l'horreur. Mais ça demande à un superviseur technique de revoir le code régulièrement, ce que beaucoup de boites ne font/ne peuvent pas trop je pense.



Et pour finir sur les ***, moi aussi j'en ai vu, dans un gros projet qui tourne depuis 20 ans maintenant, écrit à moitié en C et en C++. Ben c'était buggé, yavait un * qui était alloué mais jamais désalloué. Et le projet devait être redémarré tous les jours parce que sinon il crashait sous les fuites mémoires (pas que celle là...). Il était terrible ce projet, une fuite mémoire à chaque appel CORBA, une fuite mémoire à chaque connection d'utilisateur... c'était mon premier job, c'était formidable pour apprendre

[Shaidak]

Et voilà pourquoi je ne postulerais sûrement pas dans une boîte qui fait du C/C++. Je me garde C++ pour mes projets perso, quitte à apprendre moins de choses qu'en milieu professionnel, au moins je n'en suis toujours pas dégoûté .

Pour ce qui est de l'algo plutôt que du langage +1, à trop s'attarder sur le langage on en oublie la conception ...

Pour la maîtrise du langage C++, j'ai vu énormément de dev autre que C++ (java, php, .net ...) mentionner sur leur CV "maîtrise : XX, XX, C/C++" et je dois avouer que ça me fait toujours bondir. C' est la même chose pour l'anglais, on met "courant" voir "bilingue" quand on a eu 15 au bac ... youpi ! Bah idem pour les langages, t'en a fait à l'école (ou pas vu que tu dormais), bah tu mets maîtrise et ça passera.

Au final, ça pousse tous les dev à mettre la même chose, et on se retrouve avec de jeunes ingénieurs sortis de l'école avec un stage de 6 mois en poche grand max qui "maîtrisent" 5 à 6 langages de programmation ... bonjour l'objectivité ...

[koala01]

Salut,

My two cents :

Personnellement c'est un petit test que je fais quand je reçois des candidats pour une embauche. Il y a toujours C/C++ dans les CV et je demande quelles différences ils font entre les deux langages. Ca permet d'en apprendre beaucoup sur la vision et l'expérience qu'ils ont 1/ du C, 2/ du C++, 3/du paradigme objet.

Ca, c'est parce que tu en connais toi même assez pour faire la différence...

Seulement, avant d'arriver chez toi, un candidat aura du passer par:

1. La mise à la poubelle des CV trop long
2. La sélection parmi les CV restant de ceux qui "semblent" les meilleurs à des gens qui n'y connaissent rien
3. Un premier entretien d'embauche effectué par des gens qui n'y connaissent rien et dans lequel on parlera sans doute de tout, sauf de programmation (et où on essayera en fait bien plus de savoir si tu sera capable de t'entendre avec les autres)

Du moins, dés qu'il s'agit d'intégrer une structure un tant soit peu importante ou complexe.

Si tu venais à me dire que tu travailles dans un service RH, et que c'est toi la personne que l'on rencontre lors du premier entretien, je te féliciterais d'avoir cette approche, car j'aurai conscience que ce n'est pas ta formation d'origine

Pour moi, ce qui compte c'est la connaissance pointue de l'algorithmique de quelques éléments de maths et du paradigme de programmation utilisé. Pour quelqu'un qui maitrise ces éléments, l'apprentissage d'un nouveau langage de programmation se compte en peu de semaines avant d'en avoir la maitrise.

Dans un certain sens, je suis d'accord avec toi, seulement

Par exemple, si j'ai besoin d'un collaborateur pour un projet développé en technologie objet, je me moque éperdument qu'un candidat ait une expérience en Java en C++ ou en smalltalk, ce qui importe pour moi c'est qu'il soit parfaitement clair avec les présupposés du développement objet.

On en revient toujours au même problème...

Trop souvent, l'algorithmie ou la conception OO ne sont abordés que parce que "c'est nécessaire pour aller plus loin" dans l'apprentissage d'un langage particulier.

Du coup, l'apprentissage de la conception OO est souvent biaisé par le langage envisagé.

On devrait presque faire un sondage pour savoir qui a entendu parler de LSP ou de demeter pendant de ses cours OO... J'ai l'impression que, pour la plupart de ceux qui en ont entendu parler, c'était de manière extra scolaire ou à l'occasion d'une discussion sur un forum / une ML ou autre

[Mac LAK]

C'est très possible de bien connaître le C++ sans du tout maîtriser le C.

Ce n'est pas MOI qu'il faut convaincre, je le sais parfaitement, comme 90% des techniques un minimum confirmés qui traînent sur ce forum.

La personne à convaincre, c'est un DRH qui n'a jamais programmé de sa vie, ou un CP qui a arrêté de coder il y a 20 ans. Et ceux-là, tu peux faire ce que tu veux, dans "C++" il y a "C", donc si tu connais C++, tu connais C, point barre. Dans leur esprit, C++ n'est qu'une extension du C et non pas un langage à part.
Et, franchement, au vu de la proximité des deux langages d'un point de vue de la syntaxe et de leurs noms, peut-on réellement les en blâmer ??

Tu as le même "problème" entre Ada (83 et 95), ou Pascal/Delphi, ou même C et C (version "K&R" et version C99). Or, je peux te garantir qu'une personne développant en Ada 95, en Delphi ou en C-C99 qui se retrouve devant un projet en Ada 83, Pascal ou C-K&R va tirer une drôle de tronche...


La confusion étant inévitable dans la hiérarchie qui t'embauche, t'affecte à un projet ou t'envoie vérifier si l'ANPE est toujours là, il vaut mieux faire avec plutôt que de jouer à l'intégriste... Surtout face au code existant qui, je rappelle, a permis à la boîte de vivre suffisamment longtemps pour permettre aux "p'tits nouveaux" d'être embauchés.
Parce que lorsque l'on essaie d'aller contre les idées reçues, par exemple sur le fait qu'il est "mal" de mélanger C et C++, le discours que tu prendras sera du genre "Heu, p'tit gars, on bossait et on gagnait notre vie avec ça quand tu étais encore en primaire, on a bâti une réputation nickel avec nos produits, alors t'es gentil mais on ne t'a pas attendu pour savoir bosser". Avec un sous-entendu évident : si ça ne te plaît pas, t'es libre de partir.


Pour la remarque sur l'algorithmique : c'est bien de le mettre sur un CV, mais ce n'est pas réellement regardé par les "filtreurs de CV". C'est un point qui n'est soulevé qu'une fois arrivé au stade de l'entretien technique. Pourquoi donc ? Parce que pour un non-technique, un programme, c'est avant tout un langage de programmation et non pas une idée "abstraite". Ils s'intéresseront bien plus au fait de savoir faire un zouli dessin en UML, même totalement inutile, plutôt qu'au fait de savoir concevoir, vérifier et prouver un algo. Il n'y a que le responsable technique qui s'intéressera à ce que vous voulez dire par "algorithmique".


Je suis bien conscient que cela peut sembler choquant à certains, notamment les débutants. Mais un entretien d'embauche, c'est un "jeu" bien particulier, avec ses propres règles et ses propres pièges. Cela n'a souvent rien à voir avec votre boulot ou vos compétences techniques, donc apprenez à y jouer avec les règles établies si vous voulez vraiment avoir un boulot un jour.
Contrairement à ce que beaucoup pensent, les compétences techniques ne suffisent absolument pas à être embauché : on embauche bien plus souvent des incompétents qui ont la tchatche que des génies techniques proches de l'autisme, et aucun des deux n'a de chances réelles de terminer sa période d'essai avec succès.

[white_tentacle]

Je suis bien conscient que cela peut sembler choquant à certains, notamment les débutants. Mais un entretien d'embauche, c'est un "jeu" bien particulier, avec ses propres règles et ses propres pièges. Cela n'a souvent rien à voir avec votre boulot ou vos compétences techniques, donc apprenez à y jouer avec les règles établies si vous voulez vraiment avoir un boulot un jour.

Je plussoie totalement sur ce qui est dit ici. Soit on l'accepte dès le départ, soit on l'apprendra à la dure en faisant ses 6 mois/un an de chômage, mais être compétent techniquement et avoir l'air compétent en entretien, ce sont deux choses totalement orthogonales. Pour ceux qui ont du mal avec les entretiens, privilégiez les boites qui font des tests techniques dès le départ : ça peut permettre de sortir du lot plus facilement.

[Invité]

Pour la remarque sur l'algorithmique : c'est bien de le mettre sur un CV, mais ce n'est pas réellement regardé par les "filtreurs de CV". C'est un point qui n'est soulevé qu'une fois arrivé au stade de l'entretien technique. Pourquoi donc ? Parce que pour un non-technique, un programme, c'est avant tout un langage de programmation et non pas une idée "abstraite". Ils s'intéresseront bien plus au fait de savoir faire un zouli dessin en UML, même totalement inutile, plutôt qu'au fait de savoir concevoir, vérifier et prouver un algo. Il n'y a que le responsable technique qui s'intéressera à ce que vous voulez dire par "algorithmique".

Et même là, il est très très rare qu'on confie à un "nouveau" un travail demandant de bonnes compétences algorithmiques (et critique). En entretien, on va tester les connaissances, pour savoir si le candidat connait les "mots" de l'algorithmique. Mais, en général, ce n'est même pas utile, le CV le dit déjà.

Pour la vraie capacité d'une personne à concevoir un algo, sans construire une usine à gaz, sans tomber dans tous les pièges naifs (genre, c'est bien linéaire sur la dimension qui n'a pas d'importance, et cubique sur celle qui compte...), en ayant bon du second ou troisième coup (parce qu'un algo génial qui calcule faux, hein?), et en ayant le réflexe de tester (sans se cantonner dans les "ca doit marcher, le livre dit que c'est rapide, de toutes facons c'est O(n)"), une période d'essai ne suffit généralement pas à en être certain... (Elle permet tout au plus de débusquer la plupart de ceux qui ne sortiront jamais de leurs livres et de leurs cours).

Personnellement, un CV trop étoffé sur l'algorithmique, je ne lis pas ces paragraphes... La formation donne une idée du niveau en maths, l'experience une idée du niveau pratique, pour le reste, on voit après.

Les langages pratiqués, en revanche, c'est important. Tout le monde peut apprendre des langages, moyennant du temps, mais on n'a pas envie d'attendre, quand on embauche... Et puis, connaitre un langage, et bien programmer dans ce langage, ce sont des choses très différentes.

Personnellement, il y a plein de langages que je "lis", mais il y en a peu que j'écris, et très très peu que j'écris vite... Je n'ai encore jamais rencontré d'informaticien vraiment polyglotte...

Francois

[koala01]

Personnellement, il y a plein de langages que je "lis", mais il y en a peu que j'écris, et très très peu que j'écris vite... Je n'ai encore jamais rencontré d'informaticien vraiment polyglotte...

Francois

J'approuve, aussi bien le fond que le terme "polyglotte" qui fait référence à une langue parlée...

A l'instar des langues étrangères, on peut "apprendre" (comprenez: se débrouiller plus ou moins correctement) un langage en quelques mois, et il est bon d'en avoir appris plusieurs.

Par contre, le fait d'avoir appris un langage ne signifie pas que l'on en a aquis toutes les subtilités, et la maitrise ne vient qu'avec l'expérience et le temps.

Et la maitrise d'un langage que peut avoir une personne ne peut réellement être testée que... par quelqu'un maitrisant au moins aussi bien le sujet, c'est à dire, bien après le stade du premier entretien, et très certainement sur une durée dépassant la période d'essai (exception faite pour ceux qui prétendent maitriser un langage mais qui ne le connaissent absolument pas ou peu s'en faut )

[cf1020]

J'ai 48 ans, et 29 comme informaticien, j'ai programmé un petit peu dans tous les langages et je vous affirme qu'entre C et C++ il y a une sacrée différence. Et je peux vous dire aussi qu'au niveau des entreprises, que se soit les RH informatiques ou les Directeurs des départements informatiques, si vous trouvez 3% de connaisseurs vous avez beaucoup de chance. Ses gens sont comme les garagistes de nos jours, des assembleurs de pièces qui ne voyent qu'une chose devant eux, LES ECONOMIES D'ECHELLE et rien d'autre, la pire invention de l'homme.

[Invité]

Par contre, le fait d'avoir appris un langage ne signifie pas que l'on en a aquis toutes les subtilités, et la maitrise ne vient qu'avec l'expérience et le temps.

Oui, et même, j'ai parfois rencontré des experts d'un langage, qui en connaissaient effectivement toutes les subtilités syntaxiques, mais qui l'écrivaient assez mal, faute de pratique réelle...

Dans des langages compliqués comme le C++, c'est même une situation assez commune... L'expert langage n'est pas toujours un programmeur efficace, le programmeur efficace n'est pas toujours un expert langage (il travaille très souvent sur un sous ensemble réduit du langage, qu'il maîtrise très bien)

Francois

[Luc Hermitte]

a- Mouais, un technicien, en général, il veut quelqu'un pour développer ou maintenir un programme (existant) précis... Et si ce programme est "C++", il y a de grandes chances (pas juste dans l'industrie) qu'il soit écrit en une mixture C/C++...

Quand un programme maintenu a migré de la phase C/C++ instable (+ de 5ans d'histoire ne garanti pas la stabilité, surtout sur les composants non prioritaires en bout de course) à C++ stable (à simples coups de RAII, de string et de vector ...), je n'hésite pas un seul instant à dire que les gens à intégrer au projet devront connaitre le C++ ou être capables de s'y mettre.

Note également que les fuites mémoires, dans un nombre important de cas, ce ne sont pas "réellement" des bugs. Ca pourrait faire planter si..., c'est certain, mais ce n'est pas sensible chez l'utilisateur, et donc ca n'existe pas... (il y a bien sur des cas où ca compte, mais ces bugs là sont souvent faciles à voir et corriger, il y a plein d'outils pour cela, là encore, ils ne restent pas longtemps)

Ce ne sont pas des bugs jusqu'à des migrations de la plateforme de compilation (changement d'OS, de version de compilo, ...) qui font que les fuites (que j'employais au sens large pour erreur de manip de mémoire -> buffer overflow & cie) deviennent des bugs qui s'observent 50% du temps, et jamais au bon endroit.

Quant aux outils, ouais, ils sont sympas, sauf quand ceux disponibles ralentissent le lancement d'un composant (10s -> 30minutes) par un "manager" qui s'arrête quand on ne lui rend pas la main suffisamment rapidement. Je ne dirai pas facile. Pénible, plutôt.

[le triple étoile buggé]
a- Genre

Code :

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

1
2
3
4
function resizemontableaudetableau(elementdebase *** monptr)
{
  *monptr = realloc();
}

?

b- Euh dans ce cadre les triple étoiles ça a quoi de gênant en C ?

a- Rajoute une écriture ensuite dans une zone non-allouée, ou l'utilisation de valeurs non-initialisées.
b- Quand le simple * n'est pas compris, le triple envenime les choses.

Je ne tiens pas à ce que les réflexes des nouveaux collaborateurs soient d'utiliser ces constructs que peu savent utiliser correctement.

a- J'ai toujours trouvé assez débile ces offres d'emploi qui indiquent la connaissance de tel ou tel langage de programmation, même si elles sont majoritaires.

b- Pour moi, ce qui compte c'est la connaissance pointue de l'algorithmique de quelques éléments de maths et du paradigme de programmation utilisé. Pour quelqu'un qui maitrise ces éléments, l'apprentissage d'un nouveau langage de programmation se compte en peu de semaines avant d'en avoir la maitrise.

a- Pas quand il faut intégrer une ressource pour hier dans un projet qui tourne déjà. Quand c'est du recrutement idéal en prévision de montée en charge dans 2 mois, c'est autre chose. Mais j'avoue que je ne sais pas à quel point c'est répandu...

b- Il n'est pas rare d'avoir à développer des projets algorithmiquement simplistes. Va chercher des données en base pour tracer des courbes, tes compétences en algo ne seront pas exploitées. De plus en plus on se retrouve à intégrer des briques pré-existantes. Dans un métier donné, il n'y a guère de révolutions.

[dlandelle]

Plutôt d'accord avec C++ vu comme un sur-ensemble de C.

Mais certains sujets n'ont pas besoin d'héritage, ni d'objet.
Dans ce cas faut-il se forcer à créer des classes ?

Pour les fonctions bas niveau, FILE, handles, string, je préfère rester en C en maîtrisant l'allocation / désallocation.

Les désallocations implicites des smart pointer sont rarement comprises par un programmeur C++ qui n'a pas codé à la main ces mécanismes, et cela peut devenir aussi dangereux que puissant.

Pour moi l'intérêt de C++ est surtout de structurer le code, d'étanchéifier, de banaliser les interfaces (après spécifications) pour minimiser l'impact des refontes partielles liées à des chagement de techno.

Sur un CV je mettrais C/C++, et j'éviterai comme cela a été dit de polémiquer

[nikko34]

Les désallocations implicites des smart pointer sont rarement comprises par un programmeur C++ qui n'a pas codé à la main ces mécanismes, et cela peut devenir aussi dangereux que puissant.

bon je vais pas m'attarder sur le reste même si je pense le contraire, mais on va pas répéter 30 fois la même chose

Mais sur ce point en particulier, franchement, les smart pointers je n'ai eu aucun problème à expliquer ça à quelqu'un qui connait juste les pointeurs. Et jamais eu aucun problème pour l'instant. Et on a pas besoin de savoir en exactemetn en interne comment ça marche, mais de savoir quand et comment l'utiliser, et pourquoi faire ci et pas ça.

C'est comme boost::lambda: franchement c'est simple à expliquer. Par contre si je devais expliquer le fonctionnement interne à tous les développeurs, c'est pas gagné. C'est ce que je reprochais aux tutorials sur le site, certains allaient de suite en détail sur l'implémentation de la bibliothèque en oubliant que le client lui il veut juste savoir comment on s'en sert!

Bon après je voudrais rajouter un truc:

Il y a certaines boites qui ont le temps (donc l'argent) de créer eux mêmes leurs bibliothèques. Si google n'utilise pas boost c'est parce qu'ils ont les ressources pour faire leur bibliothèque à eux, et que de toute façon leur but est de faire mieux que la concurrence.

Si boost existe, c'est parce que la plupart des boites n'ont pas 50 personnes qui travaillent à temps plein sur leur bibliothèque et que les performances de boost sont plus que correctes. Et ça vaut pour la STL. Et effectivement pour des besoins particuliers on peut être amené à redévelopper soit même certaines parties, mais le faire systèmatiquement, pour moi c'est de la perte de temps. Après tout dépend des besoins c'est sûr.

Pour de l'industriel, faire des applis C++/boost sans fuite mémoire (pas de new qui trainent), qui ne plantent pas, et qui font leur job (temps correct), c'est pas si mal.

[Invité]

Si boost existe, c'est parce que la plupart des boites n'ont pas 50 personnes qui travaillent à temps plein sur leur bibliothèque et que les performances de boost sont plus que correctes. Et ça vaut pour la STL. Et effectivement pour des besoins particuliers on peut être amené à redévelopper soit même certaines parties, mais le faire systèmatiquement, pour moi c'est de la perte de temps. Après tout dépend des besoins c'est sûr.

Cet argument fonctionne dans les deux sens...

Pour une entreprise toute neuve, avec une équipe toute neuve, et qui développe du code tout neuf, c'est certain que redévelopper son boost ou sa STL maison est une perte de temps, et aboutira probablement à de mauvais résultats.

Mais dans le cas (à mon avis bien plus courant que le précédent), d'une boite existante, avec du code existant, qui s'est avéré suffisament correct pour être vendable et rentable, et qui utilise des outils éventuellement anciens ou bricolés, mais que tout le monde maîtrise, refondre le code pour le moderniser, c'est un gros risque...

Cela vaut pour les bibliothèques, mais aussi pour les frameworks et les compilateurs...

La dernière chose qu'un client est prêt à entendre, ce sont des choses comme

"nous avons actuellement des régressions/le développement a pris du retard parce que nous avons changé de compilateur (ou de bibliothèque)"

En pratique, le gain lié à l'utilisation de boost doit toujours être mis en parallèle avec le coût du passage. Le calcul intègre souvent le risque lié (en informatique, rien ne se passe jamais comme prévu) et l'analyse est toujours de court terme (aucune entreprise ne raisonne au delà de deux ans sur ce genre de chose, la technologie évolue trop vite).

Dans ces conditions, la "marge de gain" lié à boost (ou telle ou telle autre lib, soit dit en passant), est bien souvent insuffisante pour justifier le risque.

Francois

[nikko34]

fcharton: oui tu as raison ça dépend aussi bien sûr du contexte de la boite. Mais j'ai vu des boites redévelopper des MaBoiteString juste parce que.. ben ils ont toujours fait comme ça, sans réfléchir.

[Invité]

fcharton: oui tu as raison ça dépend aussi bien sûr du contexte de la boite. Mais j'ai vu des boites redévelopper des MaBoiteString juste parce que.. ben ils ont toujours fait comme ça, sans réfléchir.

Bien d'accord! En fait, le seul cas ou un "MonVecteur" est tolérable c'est

- s'il est utilisé depuis assez longtemps pour être réputé solide
- si s'en débarasser représenterait un cout énorme
- ou s'il est tellement simple à écrire que le cout de développement n'en est pas réellement un (je souris toujours quand on me propose d'introduire une nouvelle librairie géante pour "normaliser" un malheureux "type maison" utilisé deux fois, ou de remplacer une chose simple, par exemple une date utilisée en clef de tri, par une usine à gaz qui fait tout, parce que comme ca, hein, si on doit passer au calendrier Julien, hein?)

Francois

[Luc Hermitte]

Mouais. Le type vecteur, je l'ai déjà vu. Avec une politique d'accroissement octet par octet, et des fuites sur exceptions. Il n'a pas tenu longtemps face au vector quand j'avais repris le bébé en main. Étrangement, j'ai descendu les perf d'un calcul à plus de 24h (un ctrl-c m'avait échappé avant) à 20 minutes.

Maintenant, +1 au risque du changement, montée de niveau, etc.
Suite à une montée de niveau de compilo, on avait dû jeter la lib Tools++ de Roguewave et donc fournir des services équivalents à ceux précédemment fournis.

[Invité]

Mouais. Le type vecteur, je l'ai déjà vu. Avec une politique d'accroissement octet par octet, et des fuites sur exceptions. Il n'a pas tenu longtemps face au vector quand j'avais repris le bébé en main. Étrangement, j'ai descendu les perf d'un calcul à plus de 24h (un ctrl-c m'avait échappé avant) à 20 minutes.

Hehe, j'ai vu cela avec du code STL, remarque... Un bout de code qui gérait les distances entre éléments comme dans les listes (par des parcours au lieu de faire des différences de position), ou des situations dans lesquels le programmeur n'a pas compris qu'au lieu de trier un gros vecteur de gros machins, on peut avantageusement l'indexer, surtout quand on a besoin de plusieurs clefs de tri... (je cite ce second cas, parce que la STL pousse au crime, là... en fournissant un sort() mais pas d'index())

En général, les classes maison sont effectivement de bons suspects quand on reprend un code. Il ne faut juste pas les remplacer pour le plaisir...

Sur les changements de compilo, j'ai un souvenir précis d'un logiciel développé sous Borland (il y a une quinzaine d'années), énorme et très bien vendu sur un marché très large. Lors d'un rachat d'entreprise, et à l'occasion du portage en 32 bits, le directeur technique (quelqu'un de doué pourtant), avait décidé qu'il fallait passer à Visual, "pour la pérénnité". En fait de pérennité, on a perdu deux ans, dégouté l'équipe qui a fini par partir. Du coup, l'outil n'a pas évolué, et est mort peu après...

Ca fait réfléchir sur la nécessité des upgrades...

Francois

[koala01]

Sur les changements de compilo, j'ai un souvenir précis d'un logiciel Borland (il y a une quinzaine d'années), énorme et très bien vendu sur un marché très large. Lors d'un rachat d'entreprise, le directeur technique (quelqu'un de doué pourtant), avait décidé qu'il fallait passer à Visual, "pour la pérénnité". En fait de pérennité, on a perdu deux ans, dégouté l'équipe, l'outil n'a pas évolué, et est mort peu après...

Ca fait réfléchir sur la nécessité des upgrades...

Francois

Je crois que le changement pour le changement n'est jamais bon, surtout s'il est "motivé" par des raisonnements qui prennent plus en compte les affinités d'un personne avec un framework ou un langage (l'éternel débat XXX ca pue, YYY est bien mieux )

Par contre, si on peut remplacer un code, peut être stable, de vingt ligne par un équivalent plus sécurisant de 10 et plus dans "la lignée" de la "philosophie actuelle"il serait à mon sens dommage de s'en priver, surtout si l'auteur du code originel a pris sa pension depuis dix ans

Enfin, il y a parfois des cas tout à fait à part:

J'ai personnellement postulé pour une place dans une société où l'application phare était encore dans une version console, certes très stable et très rapide, mais qui avait atteint les limites d'évolutions que l'on pouvait envisager sur base du travail de base.

L'idée était de moderniser l'application pour lui donner une interface graphique (créée avec Qt, pour ne pas le citer) et de reprendre à peu près tout depuis le début, en évaluant les besoins actuels et les évolutions potentielles à venir.

Dans de telles conditions, même s'il est intéressant de se souvenir des problèmes rencontrés et des solutions apportées au cours du cycle de vie de la première version, il ne s'agit, ni plus ni moins, de relancer un projet complet, et, de ce fait, je trouverais particulièrement dommage de repartir avec du code ancien plutôt que de réellement partir d'une feuille blanche, et de choisir dés le départ de coder de manière "moderne".

Evidemment, je suis peut aussi être tombé sur la seule société qui ait pris une telle décision ces cinq dernières années