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

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

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

[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

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

[reptils]

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

Je suis à 100% d'accord avec ça !
Je croyais être le seul au monde à penser comme ça. sachant que certaine fois tu peux gagner bien plus que 10% de perf!

[Joel F]

Je suis à 100% d'accord avec ça !
Je croyais être le seul au monde à penser comme ça. sachant que certaine fois tu peux gagner bien plus que 10% de perf!

ca doit etre la fete du slip par chez vous c'est dingue. Pourquoi ne faites vous pas juste du C à ce moment ???

[reptils]

Quand tu arrives dans un environnement qui a un passif c'est pas évident de faire changer les choses. De plus de mon coté les perfs c'est toujours critique. Enfin il y a des gardes chapelle avec positions politiques

[Joel F]

Quand tu arrives dans un environnement qui a un passif c'est pas évident de faire changer les choses. De plus de mon coté les perfs c'est toujours critique. Enfin il y a des gardes chapelle avec positions politiques

Ok d'accord mais, pourquoi pas faire QUE du C à ce moment ?