Discussion :

[Issam_Lahlali]

Et n'oublions pas qu'il ne pourrait pas y avoir de programmes de haut niveau avec des performances correctes s'ils ne tournaient pas sur un bas niveau réellement performant, ce qui explique aussi pourquoi le C/C++ ne dégringolent pas réellement dans la liste des langages les plus utilisés.

pour cela il faut mesurer l'overhead du haut niveau sur les performances, si le fait de passer par une classe et utiliser du polymorphisme touche beaucoup au performances je serais d'accord avec toi, mais en realité le cout de passer par les concepts objets en C++ est negligable, c'est juste des redirections en plus.


je ne vois pas qu'est ce qui m'empêche comme développeur C++ de me concentrer sur le metier au lieu de rester tout le temps bas niveau donc non productif.

et proposer un framework qui fait abstraction n'est pas du tout un mal en c++ et ne touche en aucun cas les performances.

il y a une association en C++ que j'arrive pas a comprendre :

simple a utiliser => peu performant
tordu => très performant


je crois en C++ qu'on peut avoir un code très très simple ou la majorité des développeurs peuvent oublier le bas niveau, d'ailleurs on fait du C++ pour des applications métiers pas pour faire du bas niveau et de la technique.

et pour simplifier je suis pour faire abstraction a tout ce qui est compliqué une fois pour toute, et je crois pas que cette démarche va écraser les perfs, et si c'est le cas autant faire du C puisque le C++ se caractérise du C par l'abstraction notamment.

[Mac LAK]

pour cela il faut mesurer l'overhead du haut niveau sur les performances, si le fait de passer par une classe et utiliser du polymorphisme touche beaucoup au performances je serais d'accord avec toi, mais en realité le cout de passer par les concepts objets en C++ est negligable, c'est juste des redirections en plus.

Ce ne sont pas deux indirections et trois casts (résolus à la compilation) qui provoquent cet overhead, mais les tonnes de vérifications requises pour les langages de haut niveau dans leurs runtimes ou VM, ainsi que les diverses adaptations entre les données manipulées entre les deux mondes (qui te garantit qu'un langage de haut niveau se contentera de 32 ou même 64 bits pour un entier ?).

je ne vois pas qu'est ce qui m'empêche comme développeur C++ de me concentrer sur le metier au lieu de rester tout le temps bas niveau donc non productif.

J'aime beaucoup l'association "bas niveau = improductif"...

je crois en C++ qu'on peut avoir un code très très simple ou la majorité des développeurs peuvent oublier le bas niveau, d'ailleurs on fait du C++ pour des applications métiers pas pour faire du bas niveau et de la technique.

Le bas niveau, c'est AUSSI le métier, voire sa base assez souvent (acquisition/génération de signaux, contrôle/commande, automatisme, etc.). Et c'est justement au bas niveau, et technique, que le C++ est le plus utile.

Dans ma boîte, la plupart des composants réellement métier, c'est du script de haut niveau (type Python), des simulations mathématiques (modules Matlab), des synoptiques d'automatisme/visualisation, des IHM spécialisées (en Java par exemple), et le C++ en est le plus souvent absent. Par contre, il est juste en dessous pour fournir les données, bien entendu.

Faut se méfier du terme "métier", souvent utilisé à mauvais escient : classiquement, c'est quelque chose qui n'a plus grand-chose à voir avec le code. Et il y a métier et métier aussi !

Je trouve par exemple abusif le terme "métier" lorsque l'on s'adresse à d'autres développeurs, par exemple en leur fournissant une librairie de gestion audio : ça reste du code, certes spécialisé, mais du code quand même !!
On parle en général d'application métier quand on sort complètement du codage pour arriver dans un domaine où le logiciel n'existe plus autrement que sous forme d'outil, et là, le langage avec lequel on le fait n'a AUCUNE importance, seules comptent les fonctionnalités implémentées (et les performances attendues ne sont pas forcément à l'échelle de la machine...).

Demande à un automaticien de faire du C++, il te répondra Grafcet, bus de terrain et entrées/sorties et va vraiment se demander de quoi tu peux bien être en train de parler...

[Issam_Lahlali]

Faut se méfier du terme "métier", souvent utilisé à mauvais escient : classiquement, c'est quelque chose qui n'a plus grand-chose à voir avec le code. Et il y a métier et métier aussi !

Je trouve par exemple abusif le terme "métier" lorsque l'on s'adresse à d'autres développeurs, par exemple en leur fournissant une librairie de gestion audio : ça reste du code, certes spécialisé, mais du code quand même !!
On parle en général d'application métier quand on sort complètement du codage pour arriver dans un domaine où le logiciel n'existe plus autrement que sous forme d'outil, et là, le langage avec lequel on le fait n'a AUCUNE importance, seules comptent les fonctionnalités implémentées (et les performances attendues ne sont pas forcément à l'échelle de la machine...).

Demande à un automaticien de faire du C++, il te répondra Grafcet, bus de terrain et entrées/sorties et va vraiment se demander de quoi tu peux bien être en train de parler...

par metier je veux dire le but pour lequel on développe l'application, et pour arriver a ça on utilise bien sur la tuyauterie technique.

et dans des domaines comme l'automatique ou l'embarqué t'a raison on utilise plus C que C++ d'ailleurs, il y a des domaines ou le métier est la partie technique et la je suis d'accord il faut rester dans sa pensé le plus proche bas niveau puisque c'est finalement le métier a implémenter.

mais je parle des cas ou la technique représente juste la tuyauterie, dans ca cas il vaudra mieux simplifier au maximum l'utilisation de cette couche technique pour ce concentrer sur la vrai valeur ajoutée.

mais si je comprends bien tu pense que C++ est un mauvais choix dés le départ pour ce type d'application et je suis d'accord avec toi si on reste bas niveau dans notre façon de l'appréhender par contre si on essaye de remonter d'un niveau ça sera la même chose que n'importe quelle autre langage haut niveau puisqu'on a tout ce qu'il faut, il faut juste se liberer de ce piège de la couche technique

[MenshaKaine]

- une connaissance généraliste est toujours un plus, il y a du bon et du moins bon dans tous les langages, en connaître un de plus est toujours une bonne expérience
- ça t'offrira plus d'opportunités, et quand il faut manger c'est toujours bon à prendre .

Merci pour ta réponse, je partage assez ton avis.

si c'est le cas autant faire du C puisque le C++ se caractérise du C par l'abstraction notamment.

Je suis d'accord. Et beaucoup des projets auxquels j'ai participé finise en C like.

D'ailleurs côté bas niveau, beaucoup de professionnel pense que le C++ n'est pas fait pour faire de l'embarqué !

Je ne comprend pas la résistance qui existe dans la plus part des projets contre la réutilisation; le besoin de toujours tout refaire pour avoir l'impression de maitriser.

Exemple:
Lors d'un projet, j'avais choisit d'utiliser les string de la STL et la fonction find associé,j'ai du expliquer la pertinence de mon choix d'algorithme car on me reprochait de ne pas l'avoir codé !
j'avoue que je n'ai pas la prétention de faire mieux que les spécialistes qui ont codé la STL alors que mes responsable l'avait !

J'ai fit un peu de C# lors d'un projet et je n'ai pas rencontré ce genre de problème. Là les gens préféraient clairement utiliser ce qui existait.

En faite j'ai l'impression qu'une partie des gens qui font du C++ s'éclate dans des question très bas niveau alors que d'autre son plus soucieux de la "productivité".

[koala01]

par metier je veux dire le but pour lequel on développe l'application, et pour arriver a ça on utilise bien sur la tuyauterie technique.

et dans des domaines comme l'automatique ou l'embarqué t'a raison on utilise plus C que C++ d'ailleurs, il y a des domaines ou le métier est la partie technique et la je suis d'accord il faut rester dans sa pensé le plus proche bas niveau puisque c'est finalement le métier a implémenter.

mais je parle des cas ou la technique représente juste la tuyauterie, dans ca cas il vaudra mieux simplifier au maximum l'utilisation de cette couche technique pour ce concentrer sur la vrai valeur ajoutée.

mais si je comprends bien tu pense que C++ est un mauvais choix dés le départ pour ce type d'application et je suis d'accord avec toi si on reste bas niveau dans notre façon de l'appréhender par contre si on essaye de remonter d'un niveau ça sera la même chose que n'importe quelle autre langage haut niveau puisqu'on a tout ce qu'il faut, il faut juste se liberer de ce piège de la couche technique

On ne dit pas le contraire, mais, comme ce débat a été ouvert dans le sens où il faudrait inclure cela au standard du langage, on te répète encore une fois que cela n'entre nullement dans son champs d'application.

Après, si les différents acteurs intervenants dans un secteur particulier souhaitent homogénéiser les choses et, surtout, arrivent à un accord pour créer une norme d'application dans l'ensemble de ce secteur, il est clair que ce ne sera pas un mal, mais cela doit se faire en marge de la norme C++ en tant que telle (ou du moins en parallèlle)

[Issam_Lahlali]

On ne dit pas le contraire, mais, comme ce débat a été ouvert dans le sens où il faudrait inclure cela au standard du langage, on te répète encore une fois que cela n'entre nullement dans son champs d'application.

Après, si les différents acteurs intervenants dans un secteur particulier souhaitent homogénéiser les choses et, surtout, arrivent à un accord pour créer une norme d'application dans l'ensemble de ce secteur, il est clair que ce ne sera pas un mal, mais cela doit se faire en marge de la norme C++ en tant que telle (ou du moins en parallèlle)

je ne sais pas si t'a lu les posts depuis 2 jours mais le but n'est pas de faire une spec générale mais au niveau de l'entreprise, pour avoir un framework technique qui fait abstraction aux complexités pour libérer les développeurs de cette tache.

et la spec généralisé a toute la communauté C++ son rôle n'est pas de l'imposer aux autres librairies, d'ailleurs rare ceux qui implémente les normes dans n'importe quel domaine mais pour suggérer une abstraction fait par des experts dans le monde technique ce qui va m'aider lorsque je veux faire cette démarche d'abstraction au sein de l'entreprise.

et le probléme que je trouve surtout gênant dans la communauté C++ c'est le message véhiculé par ces adeptes ou toute simplification on en a pas besoin et ça sert a rien, on est des durs et rien n'est difficile pour nous

[Issam_Lahlali]

En faite j'ai l'impression qu'une partie des gens qui font du C++ s'éclate dans des question très bas niveau alors que d'autre son plus soucieux de la "productivité".

C'est exactement mon sentiment et je n'arrive pas a trouver une réponse a cette approche trop bas niveau,malgré que C++ apporte tout ce qu'il faut pour ce libérer de ce complexe technique.

[Mac LAK]

mais si je comprends bien tu pense que C++ est un mauvais choix dés le départ pour ce type d'application et je suis d'accord avec toi si on reste bas niveau dans notre façon de l'appréhender par contre si on essaye de remonter d'un niveau ça sera la même chose que n'importe quelle autre langage haut niveau puisqu'on a tout ce qu'il faut, il faut juste se liberer de ce piège de la couche technique

Sauf que si tu "montes" vers l'abstraction, tu vas te retrouver directement en concurrence avec d'autres langages, qui seront plus rapides côté développement et sans impacter de façon visible les performances côté utilisateur final !

Exemple : application distribuée basée sur une interface Web... Fais-le en C#/Java + PHP et en C++, je sais d'avance qui va gagner... Et les temps de transfert sont tellement lents par rapport à la machine que le surcoût de PHP et du langage managé seront imperceptibles !

Application distribuée basée sur TCP/IP et bases de données multiples ? Delphi/BCB vont sûrement avoir la vitesse de développement la plus courte...
Nécessité de portabilité maximale ? Java : tu trouveras TOUJOURS une différence d'implémentation dans les librairies "portables" C/C++, ou un cas vicieux jamais vu...
Besoin de gérer Windows à haut niveau (WMI et plus) ? C#/.NET vont te montrer que C++ est bien pénible pour faire ce job.

Et à "haut niveau", quel que soit le langage choisi, tu trouveras au minimum un cas de figure où C++ se fait laminer en terme de coût de développement. Il suffit de monter suffisamment haut, en fait...

Après, ne déforme pas mes propos : cela ne signifie pas que C++ est "nul", mais que comme tout langage, il a ses points forts et ses points faibles. Si tu commences à l'utiliser en dehors de son segment "idéal", tu t'exposes au risque d'être contre-productif en restant scotché au C++.


Côté frameworks plus ou moins abstraits, on pourrait dire que tu cherches à réinventer la roue, cf. les librairies comme ACE, POCO, ICE, Boost, etc. qui implémentent déjà ça en (très) grosse partie...

D'ailleurs côté bas niveau, beaucoup de professionnel pense que le C++ n'est pas fait pour faire de l'embarqué !

C++ n'est pas adapté pour faire un driver, par exemple, en effet. D'ailleurs, peu d'OS supportent les drivers écrits autrement qu'en C pur.
Toutefois, il est très adapté au bas niveau "de transfert", c'est à dire le code bas niveau (et critique, d'ailleurs) qui assure le transfert de données entre divers sous-systèmes, avec et sans traitement optionnels... Le code C++ permettant ceci est bien plus maintenable que son équivalent C, pour un overhead difficilement mesurable.
Par contre, il faut parfois se méfier de la STL en embarqué, surtout les containers complexes comme les maps : la gestion de la mémoire en embarqué, ce n'est pas toujours trivial, et on peut avoir de sales surprises côté performances par rapport à des méthodes "manuelles", mais qui tiennent compte réellement des contraintes hardware.

Je ne comprend pas la résistance qui existe dans la plus part des projets contre la réutilisation; le besoin de toujours tout refaire pour avoir l'impression de maitriser.

Tout simplement parce que tout n'est pas toujours utilisable partout : j'ai des cibles qui ne permettent pas de compiler Boost, par exemple, et sur lesquelles la STL est (pour rester poli) "un peu spéciale", sans parler de divers portage n'existant tout simplement pas.

Dans un tel cas de figure, plutôt que de porter une librairie que l'on n'a pas écrite (donc "inconnue") vers une plate-forme non supportée, pour au final n'en utiliser que 50%, il est souvent plus rapide de redévelopper les fonctions dont on a réellement besoin...

[Issam_Lahlali]

Sauf que si tu "montes" vers l'abstraction, tu vas te retrouver directement en concurrence avec d'autres langages, qui seront plus rapides côté développement et sans impacter de façon visible les performances côté utilisateur final !

si on arrive pas avec C++ a monter en abstraction a quoi sert ce langage finalement, autant laisser que du C pour les perfs et pour le reste on choisit d'autres langages, pourquoi choisir un langage ou il y a mieux pour les perfs et mieux pour l'abstraction

c'est pour cela qu'a chaque fois je dis que si on veut faire de grand projet en C++ il faut apprendre a faire abstraction a la couche technique pour arriver a une productivité proche de C# ou java, et lorsque je dis abstraction je ne veux pas dire réinventer la roue mais juste avoir des adaptateurs/facade/pont.

je trouve que le gros probléme en C++ actuellement est la couche technique ou on passe trop temps la dessus, a l'inverse des autres langages ou c'est un détail.

et je suis d'accord avec toi sur le fait d'utiliser d'autres langages qui ont un avantage sur le C++ sur la facilité de dev et d'ailleurs rare les fois ou j'ai assister a un projet ou il ya que du C++, pas mal de langages cohabitent chacun est utilisé a la partie du projet la plus adéquate.

mais il y a des boites ou le mélange de langages représente un danger et ça reste un choix a respecter et ils font tout en C++, pour ceux la je dis qu'il peuvent bien sen sortir si dés le départ ils ont une optique de faire abstraction a toute complexité technique une fois pour toute et ne pas laisser les mêmes problèmes techniques trainer pour tous les développeurs et pendant toute la durée du projet.

[MenshaKaine]

Je me demande alors à quoi sert le C++ !
Si tu montes trop haut en abstraction il est concurrencé par des langages plus "haut niveau".
Si tu descend trop bas, il vaut mieux faire du C.
Donc tu places le C++, dans une tranche "très fine" entre l'embarqué et l'applicatif ...

Le rendement apprentissage difficile de ce langage sur l'ensemble des secteurs ou l'on peut l'appliquer semble très faible ...

Je comprend que peux de personne se lance dans ce langage ou s'en détourne.

Et j'ai peur que cette effet soit constant dans le temps ! Même avec la sortie d'un nouveau standard ...

Enfin tout ça pour dire est-ce que C++ à un avenir ? Si la réponse est non, est-ce à causse du coté trop technique du C++.

[Matthieu Brucher]

Non, c'est juste que vous raisonnez de manière confinée sur un seul axe. La programmation, c'est bien plus vaste que ça. Et si avec tous les exemples donnés ici, vous ne l'avez toujours pas compris, c'est qu'il vous faut encore quelques années d'expérience avant de comprendre.

[Mac LAK]

si on arrive pas avec C++ a monter en abstraction a quoi sert ce langage finalement, autant laisser que du C pour les perfs et pour le reste on choisit d'autres langages, pourquoi choisir un langage ou il y a mieux pour les perfs et mieux pour l'abstraction

Parce que C++ a aussi des avantages sur le C, et sur d'autres langages bien entendu... En fonction de ce que tu cherches à réaliser, bien sûr.

Comprends bien ceci : il n'existe AUCUN langage universellement supérieur à tous les autres !. Il est tout à fait NORMAL que C++, comme n'importe quel autre langage, soit inadapté à certaines situations.
C'est vouloir à tout prix que ce soit le cas qui est anormal (et surtout, utopique...), ce qui rend le débat "je veux que le C++ sache tout faire mieux que tous les autres langages" stérile dès le départ : c'est impossible, tout simplement.

A propos, ne te mélange pas les pinceaux en disant "performances" : tu as les perfs au niveau machine (charge CPU, consommation mémoire, etc.), les perfs au niveau utilisateur (temps de réaction "visible" ou pas ?), et le temps de développement (qui n'est "performant" que côté comptabilité).
En fonction de la criticité (ou non !!) d'un de ces trois indicateurs, certains choix de langage sont adaptés ou non : ni plus, ni moins, et cela ne veut pas dire qu'un langage écarté sur un projet est "nul", juste qu'il y a mieux / plus pertinent.

[Goten]

Je me demande alors à quoi sert le C++ !
Si tu montes trop haut en abstraction il est concurrencé par des langages plus "haut niveau".
Si tu descend trop bas, il vaut mieux faire du C.
Donc tu places le C++, dans une tranche "très fine" entre l'embarqué et l'applicatif ...

Le rendement apprentissage difficile de ce langage sur l'ensemble des secteurs ou l'on peut l'appliquer semble très faible ...

Je comprend que peux de personne se lance dans ce langage ou s'en détourne.

Et j'ai peur que cette effet soit constant dans le temps ! Même avec la sortie d'un nouveau standard ...

Enfin tout ça pour dire est-ce que C++ à un avenir ? Si la réponse est non, est-ce à causse du coté trop technique du C++.

On l'a déjà dis et redis, cette échelle bas niveau / haut niveau est dépassé depuis longtemps pour qualifier des langages comme le C++

[Invité]

Je ne comprend pas la résistance qui existe dans la plus part des projets contre la réutilisation; le besoin de toujours tout refaire pour avoir l'impression de maitriser.

C'est marrant, j'ai souvent l'impression inverse... L'existence d'une obsession de 'ne pas refaire' chez pas mal de programmeurs C++. Ca part bien sur d'un sentiment louable, ne pas réinventer la roue et tout ça, mais ca se traduit souvent par des dérives très dommageables.

Au lieu de passer deux jours à écrire et débuguer un bout de code, on va passer une demi journée à chercher la super librairie de la mort qui répond au problème, une autre demi journèe à l'installer, pour se rendre compte qu'il faut quand même l'adapter un peu au problème (encore une demi journée), puis tester et débuguer (la dernière demi journée), et finalement constater que c'est lent, ou gourmand en ressources (ben oui, la librairie de la mort est généraliste)... Au mieux, ca n'ira pas plus vite, pour un code moins efficace. Au pire, le développeur se sera trompé de méthode ou de librairie, et là, en plus ce sera faux...

Un autre travers courant, c'est l'obsession de tout rendre réutilisable... Je ne sais plus qui disait que pour qu'une chose soit réutilisable, il fallait d'abord qu'elle soit utilisable... On se retrouve souvent (en C++) avec des hiérarchies de classes improbables, des templates incorrigibles, censés gérer des généralisations qui n'arriveront jamais (mais qui, Murphy aidant, se révèleront inadaptée à des évolutions "de bon sens").


En fait, en informatique, on réutilise énormément, mais le plus souvent, ce qu'on réutilise, ce sont des idées, des concepts et des bribes de code. A mon avis, c'est déjà beaucoup. Je ne sais pas toi, mais très peu de mon temps de développement est passé à écrire du code (je ne sais pas combien de lignes de C++ j'écris en une grosse journée, mais c'est peu, voire très peu, en fait une très très bonne journée, je "tue" des lignes de C++...). La réutilisation de code, au delà du copier coller de fonctions qui ont tourné des milliers de fois, et peuvent donc etre considérées comme propre, ca ne me parait pas aussi important qu'on le dit.

Pour la STL, il y a plusieurs aspects. Les algorithmes, les vecteurs, les string, c'est rien que du bon (sur des systèmes qui les supportent), le reste, les maps, les sets, et tout ca, c'est souvent un gros trade-off simplicité du codage contre vitesse d'exécution... Essaie à l'occasion de mettre des maps partout dans un programme, indexées par des string et tout ca... Tu vas avoir un code très gracieux à la fin... Et alors, lance le profiler, et regarde ces petites fonctions dont le nom commence par "rb" qui représentent 75% de ton temps d'exécution...

Sur du prototypage, ou du traitement de données, en revanche, les maps et les sets, c'est rien que du bonheur...

Francois

[white_tentacle]

C++ n'est pas adapté pour faire un driver, par exemple, en effet.

C'est oublier un peu vite que BeOS était écrit principalement en C++. C'est vrai que dans le contexte d'un driver, tu ne pourras pas utiliser tout C++, mais tu peux en utiliser un sous-ensemble qui n'est pas réduit à C.

[Mac LAK]

Donc tu places le C++, dans une tranche "très fine" entre l'embarqué et l'applicatif ...

Mouais, enfin, comme je le disais dans un autre topic, c'est juste que tu n'as regardé qu'un bout du monde du développement... Parce que ta tranche "très fine", moi, je la trouve plutôt épaisse et dodue !

Le secteur industriel utilise massivement le C++, mais c'est par contre un secteur très confidentiel, et "caché" pour tous ceux qui n'y ont pas déjà un pied. Tu ne le vois pas, mais crois-moi, c'est un très gros débouché pour le développement informatique. Sûr que si tu cherches du C++ dans le monde des applications web-based, ce n'est pas gagné...

A titre personnel, je trouve bien plus facilement du boulot dans l'industrie en C/C++ qu'en SSII sur la dernière techno à la mode, en tout cas...

C'est oublier un peu vite que BeOS était écrit principalement en C++. C'est vrai que dans le contexte d'un driver, tu ne pourras pas utiliser tout C++, mais tu peux en utiliser un sous-ensemble qui n'est pas réduit à C.

Autant pour moi, je n'ai jamais utilisé BeOS je dois dire (alors développer des drivers dessus... )
Disons alors "pour les OS les plus courants", donc Windows et Linux (toutes variantes confondues, inclus MacOS X).

[MenshaKaine]

On l'a déjà dis et redis, cette échelle bas niveau / haut niveau est dépassé depuis longtemps pour qualifier des langages comme le C++

Oui peut être mais j'ai l'impression qu'on tourne en rond ... Si tu préféres quels sont les domaine d'application du C++ ?

C'est marrant, j'ai souvent l'impression inverse... L'existence d'une obsession de 'ne pas refaire' chez pas mal de programmeurs C++. Ca part bien sur d'un sentiment louable, ne pas réinventer la roue et tout ça, mais ca se traduit souvent par des dérives très dommageables.

Ca doit dépendre des projets ...
Et je partage aussi ton avis sur les maps, testé et piqué

[Issam_Lahlali]

Non, c'est juste que vous raisonnez de manière confinée sur un seul axe. La programmation, c'est bien plus vaste que ça. Et si avec tous les exemples donnés ici, vous ne l'avez toujours pas compris, c'est qu'il vous faut encore quelques années d'expérience avant de comprendre.

le grand probléme c'est que C++ a dépasser depuis longtemps ce probléme mais malheureusement pas ces adeptes, le probléme encore une fois n'est pas dans le langage mais dans la manière ou la majorité l'appréhende, et comme t'a préciser s'il faut des années d'expériences pour comprendre ça, moi je dis le mieux est de l'eviter.

le constat général est que la majorité les chefs de projets, développeurs,étudiants n'ont pas encore compris les motivations C++ et pense d'une manière très proche du C que du C++, et la question qui se pose et comment minimiser ces années d'expériences qu'il faut pour bien comprendre.

[Issam_Lahlali]

A titre personnel, je trouve bien plus facilement du boulot dans l'industrie en C/C++ qu'en SSII sur la dernière techno à la mode, en tout cas...

C'est normal parce que les profils C++ commencent a disparaitre

[Mac LAK]

Et je partage aussi ton avis sur les maps, testé et piqué

Je ne suis donc pas le seul à me méfier des maps après retour d'expérience, ça me fait bien plaisir, tiens...