Discussion :

[Mac LAK]

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.

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.

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 !

[Médinoc]

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

[3DArchi]

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

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

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.

[Mac LAK]

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

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 !

[Invité]

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

[ac_wingless]

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!

[Mac LAK]

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

[Bryce de Mouriès]

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

[Peck777]

moi maintenant je mets C/C++/C# sur mon CV

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

[nikko34]

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

[Peck777]

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.