Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

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

Le , par poukill, Membre chevronné
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 !


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Médinoc Médinoc - Expert éminent sénior https://www.developpez.com
le 12/03/2010 à 16:54
J'ai eu l'occasion d'utiliser un dérivé de gcc où l'on n'avait même pas droit à un int main(int argc, char *argv) : La version pour calculatrice TI-89, où les arguments du programme sont des expressions arithmétiques de la calculatrice.

D'ailleurs, il me semble qu'on ne pouvait programmer qu'en C, pas C++. Et malloc() n'était pas recommandé, le comportement de realloc() ne pouvant pas reproduire celui du standard (un échec de réallocation ne pouvant laisser le pointeur inchangé, car l'implémentation sous-jacente déverrouillait toujours la zone pour une réorganisation mémoire (et si la réallocation échouait, il y avait forcément eu une réorganisation mémoire).

Edit: Et encore, ce n'est rien à côté de l'outil officiel de Texas Instruments...
Avatar de 3DArchi 3DArchi - Rédacteur https://www.developpez.com
le 12/03/2010 à 16:55
Citation Envoyé par nikko34  Voir le message
Je me trompe peut être, mais j'ai l'impression que pour vous le soucis principal est la portabilité.

Je vais prendre un exemple vécu.
Tu développes des composants logiciels pour un équipement (i.e. pas un PC).
Le fabriquant a plusieurs plateformes matérielles (différentes gammes low/midlle/hight cost, modèles anciens à maintenir, modèles en cours de production, modèles génération n+1 ou n+2, prototypes n'ayant pas vocation à être commercialisés, etc.) qui bien sûr n'utilisent pas le même compilateur -> donc ton code doit compiler avec ces différents compilo - certains vieux d'autres moins.
Sauf que, tu es en R&D et les dev peuvent être en avance sur le matériel. Comme on ne va pas attendre que le hard soit prêt pour tester, l'entreprise a depuis longtemps développé un environnement de simulation qui encapsule le fonctionnement bas (le niveau exact de 'bas' étant volontairement flou) de ton équipement. Cet environnement a été dvp sur PC windows avec Visual -> tu dois être compatible avec ce compilo. C'est une grosse boîte et tous les postes de dev ne sont pas forcément avec les mêmes versions...
Nouveau changement (rachat, outsourcing, politique, nouveau produit, etc..) : le simu est décliné en une version linux avec son nouveau compilo. -> il faut que tu sois encore compatible.
Bilan : les exigences de portabilité (vis à vis du matériel) et de compatibilité (vis à vis du compilo) sont très fortes même en milieu embarqué.
Avatar de nikko34 nikko34 - Membre éprouvé https://www.developpez.com
le 12/03/2010 à 17:21
Perso si nous on est dans le cas où on a pas ce soucis de portabilité, c'est bien sûr une volonté de la boite qui a un vécu. Comme le fait qu'on développe tout en interne. Et nous décidons nous même de ce que nous allons utiliser comme OS/matériel.

Mais nous ne sommes pas une société de service, ni ne travaillons pour un fournisseur d'équipement, donc on a effectivement pas du tout les mêmes contraintes.
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 12/03/2010 à 17:27
Citation Envoyé par 3DArchi  Voir le message
Bilan : les exigences de portabilité (vis à vis du matériel) et de compatibilité (vis à vis du compilo) sont très fortes même en milieu embarqué.

Je les trouve même infiniment plus lourdes que la portabilité telle que l'entendent la plupart des gens, c'est à dire "tourner sur Windows, Linux et MacOS" en utilisant la dernière version du compilateur phare de la plate-forme pour la génération.

La plupart de ces codes "portables" ne le sont pas tant que ça, ils s'appuient en fait sur des librairies multi-plateforme plus ou moins grosses (Qt, GTK, ACE, POCO, ICE, SDL, OpenGL, iconv, etc.), distribuables binairement.
Ces librairies existant sur les trois OS, on arrive effectivement à avoir du code application portable, même si les librairies sous-jacentes peuvent ne pas du tout être "portables". Typiquement, elles peuvent plus ressembler à un #ifdef géant encapsulant le code des trois OS, et plein de code bien spécifique à l'intérieur (les sources de ACE sont totalement affolants à ce niveau, par exemple).

Mais dès lors que l'on travaille sur des machines "exotiques", ces fameuses librairies-fondations n'existent le plus souvent pas, ne peuvent fréquemment pas être recompilées dessus et/ou sont bien trop grosses pour la capacité mémoire disponible. Y compris pour des choses aussi "élémentaires" que la STL ou Boost ! Par exemple, je ne peux PAS utiliser Boost, ou alors seulement un bout minuscule, car plusieurs de mes cibles ne permettent pas de compiler cette librairie (support des templates déficient sur le compilateur).

Et dans ce genre de situation, qui est assez courante en industrie, les mots "code portable" prennent un tout autre sens...

Citation Envoyé par nikko34  Voir le message
Mais nous ne sommes pas une société de service, ni ne travaillons pour un fournisseur d'équipement, donc on a effectivement pas du tout les mêmes contraintes.

Pour ma part, je suis plutôt dans la partie "équipementier" et "fournisseur", ce qui explique la pléthore de matériels différents que nous devons gérer. Mes clients, sauf cas rarissimes, n'utilisent en général qu'une seule plate-forme pour LEURS développements. C'est possible justement parce que nous fournissons du matériel qui, d'un point de vue extérieur, réagit à l'identique quelle que soit l'architecture matérielle sous-jacente.

Bref, on se complique la vie pour permettre à d'autres de se la simplifier !
Avatar de - https://www.developpez.com
le 12/03/2010 à 21:07
Citation Envoyé par nikko34  Voir le message
Perso si nous on est dans le cas où on a pas ce soucis de portabilité, c'est bien sûr une volonté de la boite qui a un vécu. Comme le fait qu'on développe tout en interne. Et nous décidons nous même de ce que nous allons utiliser comme OS/matériel.

Chez nous, la portabilité ne s'exprime pas en ces termes (nous sommes éditeurs de logiciels de poste utilisateur destinés à un marché assez spécifique, et qui font du traitement de données assez lourdes).

Comme on vit dans un monde de poste utilisateur en entreprise tertiaire, on n'a qu'un OS: Windows. Et comme on livre des produits finis, on a le choix de notre compilateur et de nos librairies... La question de la "portabilité" au sens usuel (plusieurs OS, plusieurs compilateurs) n'existe pas.

Les contraintes proviennent de l'absence totale de controle sur l'environnement d'exécution des programmes. Actuellement, sur probablement 500 utilisateurs du même soft (dans une vingtaine d'entreprises), on a à peu près toutes les versions de Windows depuis 10 ans (de 2000 à Win7, on a lâché Win98 il y a peu), et on doit bien sur s'intégrer avec les différentes versions de la suite Office parues sur la décennie... En termes de machines, on va aller de vieux trucs avec 256Mo, jusqu'à des postes récents à 4Go, et des résolutions écran allant de machins énormes, ou l'utilisateur veut voir tourner trois applis à la fois, à des 800x600, grosses polices. Et bien sur, la même appli doit avoir l'air fluide, puissante, moderne, dans les différents environnements.

Au delà des différences relatives au parc, les environnements changent en fonction de la politique d'IT des entreprises. On peut évoluer dans des milieux où le poste client est quasiment interdit (tout doit être en réseau, l'accès au disque local est limité), d'autres où c'est la seule solution raisonnable (bande passante réseau minuscule, réseau en panne tous les matins), des cas où presqu'aucun utilitaire de base n'est installé, où l'installation de quoi que ce soit demande un tombereau d'autorisations (et où donc il faut éviter tout système d'install). Et bien sur, tout ceci peut changer brutalement, à l'arrivée d'un nouveau DSI, ou d'un nouveau prestataire...

Au total, on se retrouve avec une définition un peu différente de la portabilité, mais qui se traduit par des contraintes tout aussi sévères... Par rapports aux contraintes décrites sur le monde de l'embarqué, je crois qu'elles se situent moins au centre (fonctionnalités du langage, etc...) et plus à la périphérie (IHM, accès externes). Mais la conclusion est un peu la même : prudence avec les technologies trop modernes...

Francois
Avatar de ac_wingless ac_wingless - Membre confirmé https://www.developpez.com
le 15/03/2010 à 18:15
Dans le domaine où je travaille, il y a toujours un peu de C dans les projets C++, mais franchement je demande à tous ceux de l'équipe C++ d'être compétents dans la partie C, ce qui se passe plutôt bien dans les faits. Je les recrute sur leur compétence générale en termes de capacité à faire du C++, même si aujourd'hui beaucoup de jeunes talentueux sont essentiellement formés par Java et demandent un peu de temps pour être opérationnels (traitement de choc: "#define new t_es_sur_?_verifie_d_abord_avec_ton_chef_de_projet").
Par exemple, nous avons d'excellents programmeurs C++ qui sont arrivés avec sur la même ligne de leur CV des trucs comme "Java, C/C++, Python, lex/yacc, Eclipse, etc.". Au recruteur d'aller un peu plus loin, et au besoin de passer un coup de téléphone, quitte à apprendre à déchiffrer les bouses classiques qu'on trouve dans les CV, même en provenance de bons candidats.

Là où je coince et j'appelle même pas, c'est quand je vois "CSS" entre "C/C++" et "C#"... et pourtant ça arrive!
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 15/03/2010 à 19:07
Citation Envoyé par ac_wingless  Voir le message
Là où je coince et j'appelle même pas, c'est quand je vois "CSS" entre "C/C++" et "C#"... et pourtant ça arrive!

Trier ses compétences par ordre alphabétique plutôt que par niveau de maîtrise, c'est original, tu ne peux pas le nier...

Par contre, pas certain que ce soit l'idéal pour être convoqué en entretien : comme toi, je classerai directement le CV dans la poubelle, avec un truc pareil...
Avatar de Bryce de Mouriès Bryce de Mouriès - Membre actif https://www.developpez.com
le 17/03/2010 à 10:49
Citation Envoyé par ac_wingless  Voir le message
Là où je coince et j'appelle même pas, c'est quand je vois "CSS" entre "C/C++" et "C#"... et pourtant ça arrive!

En effet elle est pas mal celle là , c'est intéressant ce que vous dites, ça permet de se renseigner comment les recruteurs voit notre CV, en tant que futur ingénieur info ça m'intéresse de voir les pièges à éviter. Pour ma part je sépare par techno; développement web (Php, html, css...), et langages pour les appli "lourdes" (Java, C/C++ ...) Par contre je ne classe pas par niveau de maîtrise mais je met en gras ce que je maîtrise le mieux et qui me semble le plus intéressant pour le recruteur.

Personnellement je ne vois rien de choquant pour C/C++, il faut effectivement juste s'assurer que la personne sait faire la différence, pendant longtemps j'ai mélangé les deux, par exemple FILE pour lire un fichier et ofstream pour écrire dedans
Avatar de Peck777 Peck777 - Membre du Club https://www.developpez.com
le 22/03/2010 à 12:34
moi maintenant je mets C/C++/C# sur mon CV

bizarrement, je n'ai pas encore eu de remarques ...
Avatar de nikko34 nikko34 - Membre éprouvé https://www.developpez.com
le 22/03/2010 à 14:50
Citation Envoyé par Peck777  Voir le message
moi maintenant je mets C/C++/C# sur mon CV

bizarrement, je n'ai pas encore eu de remarques ...

C/C++/C#/Java, tant qu'à faire?

comme 99% des CVs des nouveaux diplomés j'imagine
Avatar de Peck777 Peck777 - Membre du Club https://www.developpez.com
le 22/03/2010 à 16:55
Citation Envoyé par nikko34  Voir le message
C/C++/C#/Java, tant qu'à faire?

comme 99% des CVs des nouveaux diplomés j'imagine

certes, mais dans certaines revues destinées aux décideurs, c'est-à-dire chefs d'entreprises ou recruteurs, ces termes sont très flous et utilisés abusivement.
J'ai lu, à plusieurs endroits, que le C++ est l'évolution du C, le C# est l'évolution du C++. Ok, d'accord, on pourrait dire ça.
Mais beaucoup seront d'accord que l'amalgame est très rapide à faire, quoique techniquement parlant c'est assez vrai.
Cependant, les lecteurs de ces magazines n'y voient là qu'un argument de positionnement marketing, c'est-à-dire une inscription dans la durée d'une technologie quelconque. on pourrait faire la même chose en parlant de Windows 95/98/2000/XP/Vista/7 ou Audi A2/A3/A4/A5/A6/A8/S4/S6/....
l'accumulation des différents modèles (ou versions) sur une ligne de CV est interprété comme une faculté du diplômé à évoluer dans un langage ou d'en connaître les multiples facettes.
Bref, il faut savoir jouer avec les différents langages humains (cette fois ci) et donner à lire aux recruteurs ce qu'ils veulent bien comprendre.
Offres d'emploi IT
Ingénieur analyste programmeur (H/F)
Safran - Auvergne - Montluçon (03100)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C++