Discussion :

[poukill]

Bonjour à tous,

On le sait bien, le C++ n'est pas le C et vice versa. Le C++ contient une grande partie du C, avec quelques incompatibilités. Surtout, écrire du C++ requiert un autre mode de pensée, il est multi-paradigme.

Cependant, dans les offres d'emplois de type ingénieur / développeur assez techniques, on continue de voir fréquemment : connaissances en C/C++ ou java, bla bla bla.
Personne ne sait encore faire la différence entre le C et le C++ dans les projets digne de ce nom ?
Encore pire, si dans nos CVs on souhaite mettre C++, Python, C, etc. en indiquant bien que ce sont des langages différents, on passe pour des boulets ?

Personnellement, j'insiste dans mon CV sur la différence entre ces deux langages. Est-ce une bonne idée de tenter de précher bonne parole dans l'industrie? Ou est-ce peine perdue et il vaut mieux se résigner et laisser C/C++ dans son CV?

J'aimerai bien avoir votre avis là dessus...
A vous les studios !

[nikko34]

non, tu ne passes pas pour un boulet, mais pour quelqu'un qui s'y connait plus que les autres.

Pour les RH, managers, developpeurs qui n'y connaissent rien, bah ça les dérangera pas.

Après tout dépend des boites et de ce que tu recherches. Tu veux faire du bon boulot ou un mélange horrible cd C/C--? Bon je sais la période ne se prête pas aux choix.

Perso je serais plus enclin à embaucher un candidat qui fait bien la distinction. (et on utilise les deux en milieu industriel...et non dommage pas d'embauche)

[bretus]

Bonjour,

Cependant, dans les offres d'emplois de type ingénieur / développeur assez techniques, on continue de voir fréquemment : connaissances en C/C++ ou java, bla bla bla.

Je l'ai mis jadis aussi La raison est simple, le cours de C++ était amorcé par un cours de C et la transition pas forcément franche.

Aussi, il faut bien se dire que dans les études de types ingénieurs, tu ne sors pas en bétonnant sur un langage précis. Tu connais plutôt les rudiments de quelques langages, de sortes a être à même d'approfondir rapidement n'importe quel langage.

De plus, c'est plus facile d'arrêter de mettre des scanf dans du C++, que d'apprendre les bases de l'algorithmie, des maths et de la conception.

Enfin, le fanatisme me semble pas toujours bien venu en C++. Lorsque tu descends dans les couches, tu finis par devoir, si tu es raisonnables, travailler avec du C, ou du moins wrapper du C dans du C++ ( pilotes de base de données, opengl, CUDA,...).

Pour ma part, je t'avoue que ça ne me choque de voir un FILE pour traiter un fichier en accès direct, plutôt qu'un flux de la STL, dès lors que ce FILE n'est pas visible. En gros, dès lors que tes traitements sont dans les mêmes couches que tes libs qui encapsule du C, ça ne semble pas choquant de les coder toi aussi en C, dans du C++.

On en revient souvent au même problème en fait : La définition des modules. Qu'est ce qui est bas niveau? Haut niveau? Qu'est ce qui peut comporter des binding asm fortran? Qu'est ce qui peut comporter du C/C++ ? Qu'est ce qui ne peut comporter que du C++ "pur"? (et là dedans, qu'est ce que l'on rend générique à coup de template ou de virtual?). Qu'est ce qui peut comporter du C++ adjoint à un framework?

Je t'avoue que c'est plus ces niveaux de distinctions que je peine à "saisir" plutôt que les distinctions entre le C++ et le C.

[Invité]

Cependant, dans les offres d'emplois de type ingénieur / développeur assez techniques, on continue de voir fréquemment : connaissances en C/C++ ou java, bla bla bla.
Personne ne sait encore faire la différence entre le C et le C++ dans les projets digne de ce nom ?

Si, mais pas dans les offres d'emploi... Souvent, on écrit C/C++ quand on veut dire C++ (quand on veut seulement du C, on le précise). Ca tient en partie du tic de langage, mais aussi du fait que les deux langages partagent de la syntaxe, des compilateurs, et pas mal de pratiquants.

Personnellement, j'insiste dans mon CV sur la différence entre ces deux langages. Est-ce une bonne idée de tenter de précher la bonne parole dans l'industrie? Ou est-ce peine perdue et il vaut mieux se résigner et laisser C/C++ dans son CV?

Mettre C/C++ ou mettre C et C++, ou juste C++, ça a toutes les chances de passer inaperçu. Donc si ta conscience te dicte de les séparer, sépare les. Mais attention, un CV n'est pas un manifeste politique, y expliquer pourquoi tu les sépares, c'est effectivement lourdingue, et on se dit en le lisant qu'on va probablement voir arriver un prêcheur...

Il me semble que pas mal d'entreprises ont parfaitement conscience des différences entre C et C++, mais que la réalité du code qu'elle gèrent (dans la vraie vie, on maintient beaucoup de code et on en écrit peu) est ce mélange de C et C++, qui évolue peu à peu vers le C++, mais lentement, et qui a souvent un métro de retard sur le "moderne" (whatever this means), parce qu'on préfère généralement un vieux code qui a fait ses preuves à un truc moderne mais peut être buggé (le seul moyen d'être sur qu'un code n'est pas buggé, c'est qu'il ait tourné, et là, plus c'est vieux...). Mais la volonté de le faire évoluer existe.

Du coup, le recrutement est un exercice d'équilibre : on veut des gens qui programment de façon moderne (parce que c'est l'avenir, et que si on ne demande pas cela aux jeunes...), mais aussi des gens qui peuvent se plonger dans du code "réel", sans passer leur temps à râler, ou à vouloir tout refaire.

Et puis, les recruteurs se méfient des prêcheurs: il y en a beaucoup en informatique, qui adorent discuter sur le meilleur langage, la meilleure librairie, les bonnes pratiques... Parfois, c'est juste un trait de caractère, mais souvent, ce goût pour la palabre cache une véritable incapacité à agir, ou à prendre des décisions.

Il faut éviter de donner cette impression en entretien, et lancer un débat autour de C vs C++ (comme Linux vs Windows, l'open source et le libre...) risque de ne pas passer le bon message.

Francois

[3DArchi]

Salut,
Globalement d'accord avec François. Personnellement, j'ai pris l'habitude d'écrire C++, C (parce que j'ai bossé avec les 2 langages dans différentes missions). Personne ne m'a demandé la différence entre C, C++ et C/C++. Comme le dit François une grosse part de l'historique mélange du C, du C avec des classes et du C++ pur et dur.

[yan]

Avant de rencontrer un technique, y as les RH, commerciaux, ... et eux ils n'y connaissent pas forcement grand chose. En règle générale, surtout en SSII, ils cherchent les mots clefs et rien d'autre. Que tu écrire C/C++ ou C, C++, pour eux c'est la même chose.
Faux pas trop se prendre la tête t'as fait du C et C++, tu peut mettre C,C++. T'as pas fait de C tu mettre que C++. Pour les RH et autres cela leurs change rien. Et c'est pas à eux qu'il faut essayer de justifier.

Si tu rencontre un technique, et si cela le gêne, il te posera la question.

[Luc Hermitte]

a- Mettre C/C++ ou mettre C et C++, ou juste C++, ça a toutes les chances de passer inaperçu.

b- (le seul moyen d'être sur qu'un code n'est pas buggé, c'est qu'il ait tourné, et là, plus c'est vieux...). Mais la volonté de le faire évoluer existe.

a- Chez un RH certainement. Chez un technicien qui a demandé quelqu'un pour faire du C++, certainement pas. Maintenant si l'offre vient de techniciens parce qu'ils ont besoin de quelqu'un, et non de RH et autres intermédiaires qui veulent se constituer une base de chair fraiche, et qu'il y a bien écrit C/C++, alors oui il faut bien s'attendre à cela et non à du C++ RAIIen (la différence qui fait que ce n'est pas du C/C++, virtualité et template ne faisant aucune différence à mon goût).

Personnellement, sur mon CV "générique" je mets les langages pertinents dans l'ordre de pratique de ceux-ci. Sans faire de politique/troll, je dis juste aux techniciens que je connais la différence. S'ils estiment qu'ils ne veulent pas de profil "pur", alors il ont certainement raison, pour eux comme pour moi.

b- J'ai vu de ces horreurs, vieilles, et donc normalement rodées qui fuyaient dans tous les sens à coup de triple étoiles ... C'était pourtant une bibliothèque "critique" qui venait d'un ancien projet.

[deubelte]

A partir de quand peut-on dire que l'on maîtrise le c++? Cela dépend bien sur de la mission et du type de job, mais quand on maitrise les éléments de base, (allez, on va dire POO, Template, STL, gestion des erreurs...)
peut-on dire que l'on maîtrise le C++?

[Mac LAK]

Vu que tu parles d'industrie, je réponds donc à tes questions d'un point de vue 100% industriel.

Note que ce n'est pas du troll velu : je te dis simplement ce que j'ai déjà vu / vécu dans ce milieu, et sachant que j'épluche régulièrement des CV pour déterminer l'adéquation technique d'une personne.

Cependant, dans les offres d'emplois de type ingénieur / développeur assez techniques, on continue de voir fréquemment : connaissances en C/C++ ou java, bla bla bla.

En dix ans d'industrie (temps réel embarqué), je n'ai JAMAIS vu un projet en C++ "pur". Tu as toujours un module C quelque part : une partie embarquée, une couche système, etc. Par contre, des projets en C "pur", j'en ai vu à la pelle.

Personne ne sait encore faire la différence entre le C et le C++ dans les projets digne de ce nom ?

Rectification : on connait la différence. C'est plutôt que l'on se contrefiche de la "pureté" du programme, on veut qu'il soit efficace.
Typiquement, la STL et les flux sont bien trop lents pour le code critique, donc on les fait allègrement sauter au profit des fonctions C correspondantes. De quoi faire bondir un puriste C++, mais quand tu gagnes 10% de perfs en plus en écrivant un mix C-C++ par rapport à la version C++ "pure" et que ça te permet d'éviter d'acheter du matériel plus cher, tu oublies la "pureté" et tu fais au plus efficace.

De plus, le C++ a eu de gros problèmes de stabilité et de compatibilité de la STL : le support était inégal, les bugs nombreux, les problèmes liés aux templates récurrents. Donc, les gens ont appris à se passer de ces fonctionnalités, ou les ont remplacées par l'équivalent C qui, lui, marchait correctement.
Or, dans le milieu industriel, je te rappelle que les produits vivent pendant un minimum de DIX ANS, et que ça peut monter à TRENTE ANS sans trop forcer... Donc, quand un truc est trop instable et/ou non pérenne, il part à la corbeille.

C'est pour ces raisons que le code industriel est souvent un mélange de C et de C++.

Encore pire, si dans nos CVs on souhaite mettre C++, Python, C, etc. en indiquant bien que ce sont des langages différents, on passe pour des boulets ?

Non, pour un intégriste qui viendra casser les noix à chaque fois qu'il verra une ligne de code qui ne lui revient pas. J'ai déjà eu le cas, il n'a pas fini sa période d'essai parce qu'il passait plus de temps à râler qu'à bosser.
Classiquement, les responsables arrivent à comprendre que quelqu'un connaissent le C sans connaître le C++. L'inverse est faux : connaître le C++ sous-entends que tu maîtrises aussi le C, et que le mélange des deux ne te fait pas peur.

Personnellement, j'insiste dans mon CV sur la différence entre ces deux langages. Est-ce une bonne idée de tenter de précher bonne parole dans l'industrie? Ou est-ce peine perdue et il vaut mieux se résigner et laisser C/C++ dans son CV?

Si tu veux faire du prosélytisme dans l'industrie, franchement, t'es mal barré, et c'est assez normal : comment veux-tu justifier "ta" solution ? Les produits marchent, sont vendus, et ne "coûtent" pas grand-chose (voire "rien") en maintenance. Comment justifieras-tu de jeter du code qui marche, qui a fait ses preuves, et de consommer des mois de développement juste pour le faire "plus joli" ?

Casser du code, dans l'industrie, c'est quand il n'y a pas le choix : refonte d'architecture (pour cause de performances insuffisantes et/ou limites d'évolutivité dépassées), ou modification radicale de la plate-forme matérielle. Inutile de te dire que ça n'arrive pas tous les quatre matins, et que ce ne sera JAMAIS la dernière norme toute fraîche qui sera appliquée de toutes façons.

Juste pour te donner une idée : nous sommes en 2010, je continue de voir du code C pré-ANSI, et le code C "moderne" n'est pas totalement C90... Alors la norme C99, tu comprends bien qu'on verra ça dans dix ans, au mieux.


A ta place, j'éviterais soigneusement toute allusion "idéologique" dans mon CV, quelle qu'elle soit (langage, philo de développement, licences, etc.), sauf si tu sais dans quelle boîte tu postules.

[Invité]

a- Chez un RH certainement. Chez un technicien qui a demandé quelqu'un pour faire du C++, certainement pas.

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

Ce qu'on demandera d'abord au candidat, ce sont les OS et frameworks maîtrisés, la connaissance de certaines librairies... Ce sur quoi on le jugera, en période d'essai, c'est sa capacité à s'adapter au code existant, à lire du code des autres, à produire des choses lisibles par d'autres, et à ne pas faire (trop) de fautes le logique. La "modernité" de son C++, sauf cas très rares, c'est un détail.

b- J'ai vu de ces horreurs, vieilles, et donc normalement rodées qui fuyaient dans tous les sens à coup de triple étoiles ... C'était pourtant une bibliothèque "critique" qui venait d'un ancien projet.

Oui, ca existe aussi, et c'est pour cela qu'on refond les programmes. Mais néanmoins, quelque soit la façon dont on tourne le problème, le volume de bugs d'un code est généralement inversement proportionnel à son utilisation... Dans l'esprit des responsables (techniques aussi), un code neuf, même meilleur, c'est un risque...

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)

Et, soit dit en passant, même si ça fait planter "de temps en temps", généralement ce n'est pas très grave, c'est marrant à dire, mais les utilisateurs ont une assez bonne tolérance au plantage, ils sont en revanche très impatients quand un développement traine, ou qu'une erreur de raisonnement ou d'analyse produit un résultat faux (mais non buggé).

Une autre force des vieux programmes, c'est que les calculs qu'ils effectuent ont été "prouvés" par des années de pratique.

Francois

[Médinoc]

Un gros problème, c'est qu'il y a encore des profs qui enseignent le C/C++ (j'ai eu droit à l'un de ceux-là en BTS, j'ai du désapprendre tout pour réapprendre le C++ standard grâce à dvp).

Mais au moins maintenant, je sais programmer en C, en C++ en C∩C++, et gérer l'interopérabilité entre ces langages...

[mrjay42]

J'ai assisté à quelques discussions téléphoniques de commerciaux avec des clients et franchement je serais vous je ne prendrais pas de risque je marquerais : C/C++
Pourquoi ?
Parce que, les offres d'emplois sont rédigées comme ça et que les gens qui rédigent et reçoivent les réponses aux offres d'emplois sont rarement des gens "techniques". Par ailleurs, les clients qui emettent des appels d'offres formulent souvent les choses comme ça : "C/C++"

De plus, les clients et les commerciaux d'un point de vue technique sont des gens très peu précis !
Comme vous, j'ai entendu des phrases qui font bondir :
"Et votre ingénieur il connait les SGBD : mysql ? postgre ? eclipse?"
Et le commercial de répondre :
"oui oui, pas de problème".
Personne ne relève le fait qu'eclipse n'est pas un SGBD ^^

Ou encore ce commercial qui croyait qu'une base de données c'était une machine, comme un magnétoscope ou un grille pain.
"Mais non, 'Jean-Luc' (j'aime à penser que les commerciaux s'appellent Jean Luc), une base de données c'est un logiciel, installé sur un ordinateur...Tu vois ton PC sur lequel tu travailles ? Il peut tout à fait accueillir une ou plusieurs base de données"

[JolyLoic]

L'inverse est faux : connaître le C++ sous-entends que tu maîtrises aussi le C, et que le mélange des deux ne te fait pas peur.

Le mélange des 2 ne me fait pas peur, par contre, je n'estime pas maîtriser le C. Si je devais développer un module en C, je me trouverais bien impotent. Sur mon cv, je marque sans complexes C++ : Expert (et j'étaye cette dénomination), c : Notions. Ce n'est pas du prosélytisme, juste une vision claire de mes capacités.

A ta place, j'éviterais soigneusement toute allusion "idéologique" dans mon CV, quelle qu'elle soit (langage, philo de développement, licences, etc.), sauf si tu sais dans quelle boîte tu postules.

Sur ce point, d'accord.

Comme vous, j'ai entendu des phrases qui font bondir :
"Et votre ingénieur il connait les SGBD : mysql ? postgre ? eclipse?"
Et le commercial de répondre :
"oui oui, pas de problème".
Personne ne relève le fait qu'eclipse n'est pas un SGBD ^^

C'est tout à fait le genre de question que je poserais, mais simplement pour juger du sérieux du commercial... Un commercial qui te répond oui, aucun problème sur un truc où tu sais qu'il y a des problèmes, tu es en droit de douter sur les points où tu ne sais pas s'il y en a...

[Mac LAK]

Le mélange des 2 ne me fait pas peur, par contre, je n'estime pas maîtriser le C. Si je devais développer un module en C, je me trouverais bien impotent. Sur mon cv, je marque sans complexes C++ : Expert (et j'étaye cette dénomination), c : Notions. Ce n'est pas du prosélytisme, juste une vision claire de mes capacités.

Je te comprends, mais c'est pourtant ainsi que ce sera interprété : "Le C++, c'est du C avec des objets. Si tu connais le C++, tu connais le C, point barre".

Je sais : c'est faux, biaisé et tout ce que tu veux. Ce sera quand même interprété ainsi dans 99% des cas...

[S-SaS]

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.

[S-SaS]

Classiquement, les responsables arrivent à comprendre que quelqu'un connaissent le C sans connaître le C++. L'inverse est faux : connaître le C++ sous-entends que tu maîtrises aussi le C, et que le mélange des deux ne te fait pas peur.

Et pourtant :
- j'utilise les flux I/O et pas FILE
- j'utilise << et les strings et pas strxxx et les "xxx\0"
- je fais des class et pas de struct
- j'utilise vector<vector<xxx>> et pas **tableau
- etc.

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

[Mat007]

Salut,

Faut voir aussi que si c'est un débutant qui marque C/C++ on se doute bien que de toute façon il n'y connaît trop rien à rien et que ça ne va pas changer grand chose.
Par contre si c'est quelqu'un qui commence à avoir plusieurs années d'expérience c'est supposé dire ce que ça veut dire.

Le CV ça va dans les deux sens, c'est aussi pour que le candidat exprime ce qu'il souhaite faire.
Après quelques années on peut se permettre de ne lister que ce qu'on aime et maîtrise, et pas juste aligner pelle-mêle une série de notions vaguement entrevues pendant ses études.
Du coup si on veut faire du C++ alors il ne faut à mon avis pas hésiter un seul instant à ne marquer que C++ (et passer sous silence les 3 ans passés sur le projet machin en Ada ).

MAT.

[abgech]

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.

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.
Idem pour les développements de bas niveau, qu'il ait une expérience en C, en assembler (encore passablement utilisé dans certains cas de figure) m'est totalement indifférent, par contre qu'il connaisse parfaitement la théorie et la pratique (en n'importe quel langage) de la programmation concurrente ne m'est pas du tout indifférent.

La programmation n'est pas une affaire de langage, c'est une affaire d'algorithmique.
Au cours de ma longue carrière, j'ai eu l'occasion de programmer réellement (pour des projets effectifs) dans au moins une vingtaine de langages différents allant du Fortran (mon langage d'initiation) au Cobol (on ne fait pas toujours ce que l'on veut, il faut aussi gagner sa vie, mais je lai abandonné dès que j'ai pu) en passant par divers assembler, le PL1, C, Ada, APL (ça, c'était plutôt pour le plaisir), etc. Je n'en tire pas une quelconque gloriole, une bonne connaissance de l'algorithmique m'a été bien plus utile.
À titre anecdotique, j'ai appris le C il y a une trentaine d'années, tout seul, comme un grand (en faisant tous les exercices du K&R), à l'occasion de 3 semaines de vacances au bord de la mer. Je me faisais tellement ch* sur la plage (mais, comme me le disait Mme, l'air marin, c'est bon pour les enfants) que j'avais trouvé ce moyen de me distraire. Ce fut le divertissement le plus rentable de toute ma vie .

[kamus]

La programmation n'est pas une affaire de langage, c'est une affaire d'algorithmique.

Tout à fait , sauf qu'aujourd'hui , on va demander à un candidat de connaître tel ou tel framework d'un language , même plus juste le langage lui même , pour des questions de rapidité de production.

Et sinon , combien de gens disent maîtriser la POO sans connaître les bases de l'algo procédurale , ça me fait toujours sourire.

Pour répondre à la question C,C++ sur un CV , c'est juste une formulation classique pour les DRH , il ne faut pas trop se prendre la tête dessus.

[SurferIX]

b- J'ai vu de ces horreurs, vieilles, et donc normalement rodées qui fuyaient dans tous les sens à coup de triple étoiles ... C'était pourtant une bibliothèque "critique" qui venait d'un ancien projet.

Genre

Code :

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

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

?

...

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

Si tu veux faire une fonction qui réalloue dynamiquement un pointeur sur des tableaux, si tu peux faire autrement, je suis vivement intéréssé, je dormirai moins bête ce soir ! Merci !