Le C++ dans l'industrie = mélange C/C++ ?

Citation:

---

Envoyé par koala01

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

---

Ce choix "feuille blanche" vs "refonte" n'est pas du tout anodin. Je sors juste d'un projet qui a pris beaucoup de retard parce qu'on est partis sur une idée de "feuille blanche", sans bien se rendre compte de ce que cela impliquait...

A mon avis, la difficulté est la suivante...

Une application vieillissante est souvent bâtie autour d'une architecture ancienne, selon des principes qui sont de plus en plus difficiles à respecter, en imposant des limites qu'on voudrait dépasser. De ce point de vue, une réécriture complète s'impose.

Mais, et on l'oublie presque toujours, ladite application comporte souvent un très grand nombre de petits modules, qui marchent très bien (c'est pour cela qu'on n'en parle pas), et qui ont parfois été très durs à mettre au point. S'il faut les refaire, sans régression, cela risque de prendre beaucoup de temps. Dans ce contexte, on préfèrerait refondre, en conservant ces modules.


En général, la réécriture totale gagne, parce qu'on pense la réécriture en termes de fonctionnalité manquantes, et pas de fonctionnalités présentes (cela participe du même raisonnement que le développement de ses propres classes String et Vector), et le début du projet (tant qu'on reste dans les grands principes) donne raison à ce choix.

C'est après, quand les utilisateurs commencent à râler parce que les exports, les sauvegardes, la compatibilité, les petits machins qui gagnaient un temps précieux, manquent, qu'on regrette parfois ce choix... On s'aperçoit alors que la mise au point prend un temps bien plus grand que prévu. Et c'est là qu'on entre dans le dialogue de sourd : "c'est plus lent/moins pratique qu'avant", "oui mais les limites sur le nombre de lignes/colonnes/fichiers de l'application précédente ont disparu", "oui mais j'aimais mieux avant..."


Personnellement, je pense qu'à l'avenir, je privilégierai toujours la refonte profonde du code existant. C'est beaucoup plus exigeant (même sur un code qu'on a écrit soi même), mais je pense que c'est également plus efficace.

Et c'est là qu'une vraie méthodologie de redéveloppement fait cruellement défaut.

Francois

J'ai été dans une boite par le passé ou une pseudo-STL était spécifiquement écrite. Vu le niveau des développeurs C++ de la boite, qui était tout a fait excellent (j'y ai beaucoup appris), je me demandais pourquoi s'être pris la tête à refaire une STL incomplète et légèrement différente?

J'ai donc fini par demander et j'eu ma réponse :: nous travaillions avec des téléphones portables, des PDA et autres hardware embarqué et il n'était pas toujours possible d'avoir 1) une STL 2) dont le comportement soit strictement le même partout 3) portable sur toutes les plateformes en question -- limitations de certains compilateurs.
Du coup cela m'a semblé tout a fait justifié. Je ne sais pas si ça serait encore justifié aujourd'hui mais lorsque ce code avait été mis en place (moins de dix ans avant) c'était une bonne idée pour éviter tout un tas de problèmes.

Ces mêmes developpeurs m'encourageaient a utiliser STL/BOOST et même Lokki dans mes autres projets (persos) parcequ'ils en voyaient tout a fait le bénéfice.

Je pense que les cas où avoir sa propre STL est justifié reste rare mais existe toujours, parcequ'il existe toujours des cas où on a des contraintes fortes ou des contraintes historiques.

En effet, l'embarqué tend à avoir des problèmes avec les standards.

Citation:

---

Envoyé par Médinoc

En effet, l'embarqué tend à avoir des problèmes avec les standards.

---

Et c'est un euphémisme... ;)

Citation:

---

Envoyé par Mac LAK

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!

Citation:

---

Envoyé par reptils

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

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 :mrgreen:

Citation:

---

Envoyé par 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 :mrgreen:

---

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

Citation:

---

Envoyé par Joel F

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

---

Parce que le C++ offre tout un tas de fonctionnalités pratiques. Je ne suis problablement pas le seul programmeur C à être tombé de ma chaise en découvrant le C++ (en fait, c'avait été l'objective C, le bouquin de Cox). Chacun reconnait les apports du C++. La question est de savoir s'il faut, pour en bénéficier, "renier" le C...

Sauf contrainte externe, je ne vois pas très bien l'intérêt de se priver du C++ (y compris la STL : ne pas avoir a récrire un set, quand on n'y est pas obligé, ne pas avoir à réfléchir sur sort() ou sur merge(), voire savoir qu'on peut bâtir un tas sans avoir à exhumer le vieux bouquin qu'on a lu il y a longtemps, c'est un vrai luxe).

Une fois de plus, la considération qui prime, c'est l'efficacité, en terme de rapidité du code, d'utilisation de compétences (pas mal de vieux programmeurs C++ viennent du C), ou de lisibilité du code (si toute l'équipe lit la "mixture", il est idiot d'essayer de lui imposer un style, à des fins de beauté formelle).

Dans pas mal de gros projets, l'application utilise un mélange de langages (parfois un macrolangage un peu fonctionnel, du C dans les librairies de base, des scripts ici et là...), et ça ne gêne personne. La proximité syntaxique du C et du C++ permettent ce mélange à un niveau plus bas (celui du code source), pourquoi s'en priver?

Francois

Citation:

---

Envoyé par fcharton

Dans pas mal de gros projets, l'application utilise un mélange de langages (parfois un macrolangage un peu fonctionnel, du C dans les librairies de base, des scripts ici et là...), et ça ne gêne personne. La proximité syntaxique du C et du C++ permettent ce mélange à un niveau plus bas (celui du code source), pourquoi s'en priver?

---

On est d'accord là.

Citation:

---

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

---

Parce que n'importe qui qui défend le fait que le C est plus performant que le C++ se plante totalement :) (sauf s'il parle du temps de compilation, là :aie: )

Quelque soit un programme C, il existe un programme C++ au moins aussi performant : au pire, le même programme, puisqu'un programme C est un programme C++ valide (je sais, c'est à nuancer avec C99). Et régulièrement, il est possible de faire des optimisations supplémentaires en faisant résoudre certaines choses à la compilation.

Citation:

---

Envoyé par Joel F

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

---

Parce qu'il y a AUSSI du code non-critique à côté, et qu'il est plus simple à écrire en C++... C'est pourtant évident, il me semble.
Il y a même du code tellement peu critique (mais tellement souvent modifié...) qu'il tourne dans un interpréteur Python ou LUA embarqué. Tout est question de contexte.

Citation:

---

Envoyé par white_tentacle

Quelque soit un programme C, il existe un programme C++ au moins aussi performant : au pire, le même programme, puisqu'un programme C est un programme C++ valide (je sais, c'est à nuancer avec C99). Et régulièrement, il est possible de faire des optimisations supplémentaires en faisant résoudre certaines choses à la compilation.

---

C'est effectivement à nuancer : on ne fait en général pas vraiment du C, dans ce cas là, mais plutôt du code qui est dans l'intersection des deux langages. Mais c'est en utilisant des structures plus proches du C que du C++, car étant plus bas niveau (et, hélas, nettement moins sécurisées, toute médaille a son revers), elles sont plus performantes.

Au final, le code est effectivement compilé en C++ et non pas en C, mais le code ressemble plus à du C qu'à du C++.

Citation:

---

Envoyé par Mac LAK

Au final, le code est effectivement compilé en C++ et non pas en C, mais le code ressemble plus à du C qu'à du C++.

---

en fait, c'est relativement intéressant ce point. A croire qu'il faudrait presque 3 denominations (C, C compilé C++ et C++).

Bon point sur LUA et python aussi, ca m'avais echappé.

J'en utilise déjà trois. Par contre, autorises-t-on l'emploi de cout (mais pas de std::string, hein) et diverses choses incompatibles avec le C90 (comme les variables déclarées en milieu de bloc) dans le "C compilé C++" ? Car c'est un cas assez courant...

Citation:

---

Envoyé par Médinoc

J'en utilise déjà trois. Par contre, autorises-t-on l'emploi de cout (mais pas de std::string, hein) et diverses choses incompatibles avec le C90 (comme les variables déclarées en milieu de bloc) dans le "C compilé C++" ? Car c'est un cas assez courant...

---

J'ai l'impression qu'on y met pas mal de choses :

- cout, et les sorties de base des iostream
- new([]) et delete([]) à la place de malloc et free
- les commentaires sous les deux formes (enfin bon, ca c'est standard, je crois)
-les parties les plus évidentes de la stl, string à mon avis, et même vector, et les algos de base (min, max, etc...)

En fait, le C++ est alors vécu comme une extension de la librairie C.

Francois

Citation:

---

-les parties les plus évidentes de la stl, string à mon avis, et même vector, et les algos de base (min, max, etc...)

---

Pour moi, ce dernier point, c'est déjà du "vrai" C++.

Citation:

---

Envoyé par Médinoc

J'en utilise déjà trois. Par contre, autorises-t-on l'emploi de cout (mais pas de std::string, hein) et diverses choses incompatibles avec le C90 (comme les variables déclarées en milieu de bloc) dans le "C compilé C++" ? Car c'est un cas assez courant...

---

Personnellement, j'ai bien plus que 3 cas...

• C ou C++ : Évident, on est "stricts" sur chacun des deux. Seuls cas où j'applique une quelconque norme de langage, sinon, dans les autres, c'est "tronc commun" de rigueur (comprendre "norme d'il y a 10 ans au bas mot").
  
  
• "C++ without classes" : C++ correct, mais en code procédural et, donc, sans classes au niveau utilisateur.
  
  Pas de restrictions pour utiliser des flux, des containers ou quoi que ce soit d'autre. Utilisé principalement pour les parties "routines" des librairies.
  
  
• "C with classes" : Des classes, éventuellement de la STL, mais des E/S "C" exclusivement (notamment, aucun flux).
  
  Utilisé principalement pour pallier les STL pourries de certaines plate-formes.
  
  
• "C inter C++" : je ne mets alors RIEN qui soit spécifique à un langage (= qui clashe dans l'autre). Donc, il n'y a pas de flux, les malloc sont castés, les commentaires sont "C" et pas "C++", aucun entête C++ "pur" n'est inclus, etc. La plus stricte intersection des deux langages, le tronc commun pur et dur.
  
  Le but d'un code comme ça est d'être hyper performant, portable et auto-testé (pour éviter les régressions idiotes), mais surtout le but est de ne plus jamais avoir à le retoucher. Parce que bon, la maintenance d'un code pareil qui définit des trucs en compilation conditionnelle pour une demi-douzaine de CPU et compilateurs, ça va bien 30 secondes, mais zéro c'est encore mieux. C'est du "write-only" : ce n'est pas fait pour être beau, c'est fait pour être efficace.
  
  Il fait ce qu'on lui demande (l'optimum), et ceci quel que soit le compilateur utilisé, du vieux compilo C pré-ANSI au tout dernier G++/VS-C++, et s'il le fait correctement, on revoit le code au prochain changement de matériel, c'est à dire dans dix ans... Et on le jettera alors pour en réécrire un pour le nouveau matos ! :mrgreen:
  
  
• "Crucify Him" : Un mélange infect (et surtout non cohérent) des autres modes... :twisted:

Je programme pas mal en C∩C++, mais je tends à l'étendre un peu par l'usage de macros (notamment pour mes casts: mes macros deviennent des casts C++ quand je compile dans ce langage).

Citation:

---

Envoyé par Médinoc

Pour moi, ce dernier point, c'est déjà du "vrai" C++.

---

vector et string probablement, ce sont des classes. Les algos STL, vu que la plupart supportent des pointeurs en lieu et place des itérateurs, pour un non initié, ca ressemble furieusement à une bibliothèque utilitaire C, non?

Si tu n'as pas vu la directive using que j'ai cachée quelque part, dans un code C, je ne crois pas que tu tiques si tu vois

sort(ptr, ptr+nb);

ou même

find(tab, tab+nb, val);

Francois

Je me trompe peut être, mais j'ai l'impression que pour vous le soucis principal est la portabilité.

J'avoue que j'ai des soucis bien différents, dans le sens où on peut se permettre d'utiliser des ordinateurs avec des compilateurs qui respectent le standard, en programmant nous en respectant le standard et surtout sans bibliothèques maisons énormes mais juste le strict nécessaire. On ne va pas se trimballer 40 standards différents pour le plaisir. Enfin on peut se permettre d'en avoir qu'un quoi.

Le jour où on change carrément de marque/ou une grosse évolution du matériel embarqué, on prendra quelque chose respectant aussi le standard (on aura au mieux un gcc plus récent, au pire le même qu'actuellement). (enfin on sait jamais c'est sûr).

Et pour nos applis industrielles ne fonctionnant pas sur matériel embarqué, C++/boost et c'est la fête.

Citation:

---

Envoyé par nikko34

Je me trompe peut être, mais j'ai l'impression que pour vous le soucis principal est la portabilité.

---

Pour moi, c'est clairement un problème de portabilité ET d'efficacité, les deux sont indissociables pour éviter des suites sans fin de double/triple/quadruple développement, avec le cortège de régressions potentielles que cela entraînerait...
Bon, pour des raisons évidentes de maintenabilité minimale, l'ASM inline est interdit en dehors des bootstraps et des drivers (choses hautement NON portables par nature), on reste quand même au moins en C dans le code portable.

Citation:

---

Envoyé par nikko34

J'avoue que j'ai des soucis bien différents, dans le sens où on peut se permettre d'utiliser des ordinateurs avec des compilateurs qui respectent le standard, en programmant nous en respectant le standard et surtout sans bibliothèques maisons énormes mais juste le strict nécessaire. On ne va pas se trimballer 40 standards différents pour le plaisir. Enfin on peut se permettre d'en avoir qu'un quoi.

---

Tu as bien de la chance... La plupart de mes plate-formes n'ont qu'un seul et unique compilateur disponible, exception notable de Windows et Linux bien sûr, et certains ne sont même pas ANSI.

Citation:

---

Envoyé par nikko34

Le jour où on change carrément de marque/ou une grosse évolution du matériel embarqué, on prendra quelque chose respectant aussi le standard (on aura au mieux un gcc plus récent, au pire le même qu'actuellement). (enfin on sait jamais c'est sûr).

---

Disons que même en restant sur du GCC, tu peux avoir de sales surprises... Comme devoir utiliser un GCC 2.95 sur une cible, par exemple, et qu'un pingouin à côté a fait des sources qui ne compilent pas sans un GCC 4.x ! ;)

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

Citation:

---

Envoyé par nikko34

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

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.

Citation:

---

Envoyé par 3DArchi

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

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 ! :mrgreen:

Citation:

---

Envoyé par nikko34

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

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!

Citation:

---

Envoyé par ac_wingless

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

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

Citation:

---

Envoyé par ac_wingless

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à :mouarf:, 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 :mrgreen:

moi maintenant je mets C/C++/C# sur mon CV 8-)

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

Citation:

---

Envoyé par Peck777

moi maintenant je mets C/C++/C# sur mon CV 8-)

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

Citation:

---

Envoyé par nikko34

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.