Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le C++ dans l'industrie
Un affreux mélange de C et de C++ ?

Le , par poukill

21PARTAGES

1  0 
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 !

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de yan
Rédacteur https://www.developpez.com
Le 09/03/2010 à 10:33
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.
1  0 
Avatar de Mac LAK
Inactif https://www.developpez.com
Le 09/03/2010 à 15:06
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.

Citation Envoyé par poukill Voir le message
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.

Citation Envoyé par poukill Voir le message
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++.

Citation Envoyé par poukill Voir le message
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.

Citation Envoyé par poukill Voir le message
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.
1  0 
Avatar de Médinoc
Expert éminent sénior https://www.developpez.com
Le 09/03/2010 à 17:24
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...
1  0 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 08/03/2010 à 17:41
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)
0  0 
Avatar de bretus
Membre éprouvé https://www.developpez.com
Le 08/03/2010 à 20:09
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.
0  0 
Avatar de
https://www.developpez.com
Le 08/03/2010 à 22:05
Citation Envoyé par poukill Voir le message
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.

Citation Envoyé par poukill Voir le message

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
0  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 09/03/2010 à 9:59
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.
0  0 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 09/03/2010 à 14:05
Citation Envoyé par fcharton Voir le message
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.
0  0 
Avatar de deubelte
Débutant https://www.developpez.com
Le 09/03/2010 à 14:15
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++?
0  0 
Avatar de
https://www.developpez.com
Le 09/03/2010 à 16:59
Citation Envoyé par Luc Hermitte Voir le message
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.

Citation Envoyé par Luc Hermitte Voir le message

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