Développer en C++ ?

Désormais, et grace à Arnaud Meurgues, le monde entier sait que

John Deuf wrote:

C'est comique parce que, quand on écoute les débutants, ils disent
l'inverse : on peut pas trouver de boulot si on a pas au moins 2 ans
d'expérience.

En général, les entreprises demandent « des débutants avec 5 ans
d'expérience ». Ça permet d'avoir un salaire de débutant, mais avec tout
de même de l'expérience.
Je ne pense pas qu'elles en trouvent souvent... :-)

L'autre jour, j'ai vu une annonce qui demandait un développeur "avec au
moins 5 ans d'expérience en .NET/C#". Ca rique aussi d'être dur à
trouver ... :-))

--
I

Fabien LE LEZ <gramster@gramster.com> writes:

On Tue, 10 Jan 2006 11:36:35 +0100, "Rémy" <remy.bertrand@wanadoo.fr>:

Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il
fait un peu plus de bugs.

Et puis, il y a aussi un petit détail : une entreprise qui a un
employé compétent, va généralement chercher à le garder, sauf accident
(dépôt de bilan ou autre).

Il y a aussi un autre probleme: quelqu'un qui arrive a un niveau qui
n'est pas au bas de l'echelle depasse des gens... pour que ce soit
bien accepte, il faut
- que la competance du nouvel embauche soit reconnue, hors il a au
moins une competance qu'il n'a generalement pas: celle de
l'historique et des particularismes de la boite, donc il doit
compenser sur le reste et sur sa capacite d'adaptation
- que personne en interne ne puisse raisonnablement viser le poste;
donner l'impression qu'on prefere des gens externes a des gens
internes a competance percue comme egale, ca passe mal.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Pour moi, .Net c'est la réponse à divers problèmes du développement en
général sous Windows. Le grand nombre de technologies qui s'entremêlent
comme elles peuvent à partir de fondations qui datent de MS-DOS
(DDE->OLE->OLE 2->COM->DCOM..., DOS->Win16->Win32->Win64...). Tout ça en C
dans un monde hétéroclite où des programmeurs utilisent avant tout
d'autres langages +/- objet (C++, VB, Delphi,...).
L' interface est "C" certes, pour permettre à un maximum de languages de

pouvoir l'utiliser.
Mais les concepts derrière COM par exemple sont tout ce qu'il y a de plus
modernes...

Et ça, c'est pour le développement pur. Pour le développement web c'est
pas vraiment mieux il me semble, l'administration système aussi, ... Un
vrai sac de noeuds issu de plus de 20 ans d'évolution. Rajoutez les
problèmes de sécurité très à la mode, de productivité, de déploiement,
etc...

Je sais plus qui a dit qu'on peut toujours ajouter de la complexité dans
un système, jamais l'inverse. Pour moi, Microsoft a donc décidé de batir
un nouveau système, où ce qui change ce n'est pas tellement les services,
mais les fondations. La compatibilité binaire n'est plus un problème, tous
les langages/domaines se mélangent comme on veut.
Et sur ces nouvelles fondations, on refait du neuf avec du vieux, avec de
temps en temps de réelles nouveautés quand même. Sauf que tout est
beaucoup plus cohérent, interopérable, sécurisé, simplifié...
Tu peux coder un generic (~template) dans une assembly (~ dll) en
n'importe quel langage et l'utiliser depuis n'importe quel autre. C'est
tout bête, mais c'est bien agréable.
Le développement GUI, SQL (Server), Web et même l'admin système se font
dans le même environnement. Si tu connais C#, à _priori_ tu peux toucher à
tout ça.
Pour moi, c'est la réelle nouveauté de .Net, sa réelle force.
Je suis peut être le seul à le penser, mais je continue d'être bluffé par

COM, et je suis déçu que Microsoft soit passé à .Net.
J'ai été élevé au Windows, donc je ne suis sans doute pas objectif. Je
trouve que les concepts derrière COM étaient tout bonnement (encore)
révolutionnaires (surtout à grande échelle dans un OS) et ils sont loin
d'avoir été exploités comme ils le méritent. Je trouve que Microsoft a eu
beaucoup d'audace d' intégrer une telle technologie.
Qu'est ce qu'on nous propose maintenant? Avec dot net: une usine à gaz, avec
nouveaux languages, nouveaux dialectes, une machine virtuelle (pas installée
sur toutes les machines), etc. Et on va vivre dessus pendant des années...
(très sincèrement: quel intérêt d'une machine virtuelle, pour exécuter une
application sur Windows???)
Ce que Microsoft aurait dû faire je pense, c'est simplifier la façon
d'écrire des composants COM, pour C++, pour C, et autres. Aujourd'hui...
combien de languages vont pouvoir se permettre le passage à .Net...? C++ a
été dialectisé: en avait t'on vraiment besoin??
Bien sûr, COM ne disparait pas avec .Net, mais il va être marginalisé,
puisque les gens vont écrire du .Net plutôt que du COM.

Les web services machin chose, c'est du marketing.

Typiquement, si on veut faire une application GUI pour un seul OS, on
la développe sous Windows, car c'est le plus gros marché.

Mais il est de plus en plus facile, grâce à des bibliothèques comme
wxWidgets, de faire des applications multi-plate-formes, et donc
d'encourager l'utilisation de MacOSX et de Linux.

Pour endiguer le phénomène, Microsoft décide de faire en sorte que les
programmeurs ne sachent faire que de la programmation Windows. .Net
était né.

Ca fait un peu théorie du complot :-) Surtout que c'est pas à la fac que
le programmeur va apprendre .Net.
Je crois que c'est beaucoup plus simple. MS avait besoin d'offrir une
nouvelle impulsion au développement sous Windows, et de rester celui qui
mène la dance. Je crois que c'est réussi.

Effectivement, il fallait proposer une alternative à Java, et ils ont
mélangé toutes leurs idées et technologies ensemble, pour nous sortir du
.Net.

--
Aurélien Regat-Barrel

On Tue, 17 Jan 2006 13:01:29 +0100, "azert" <aze@erty.com>:

L'autre jour, j'ai vu une annonce qui demandait un développeur "avec au
moins 5 ans d'expérience en .NET/C#". Ca rique aussi d'être dur à
trouver ... :-))

Un ancien programmeur de chez Microsoft, qui a connu les premiers
développements .Net, peut-être ?

L' interface est "C" certes, pour permettre à un maximum de languages de
pouvoir l'utiliser.
Mais les concepts derrière COM par exemple sont tout ce qu'il y a de plus
modernes...

Tout à fait. Beaucoup de technos tiennent la route conceptuellement.
Mais pour COM toujours, sa mise en oeuvre est laborieuse, vraiment. Les
méta-infos dans un fichier idl/tlb, le downcasting dynamique
(QueryInterface) qui n'est pas celui du langage (si ce dernier le
supporte), la gestion manuelle de la durée de vie des objets, le
marshaling, l'utilisation de VARIANT, l'introspection, etc...
Toutes ces contraintes techniques sont élégament résolues par .Net,
grâce à l'assistance du framework à tous ces niveaux.
COM est un standard binaire que les langages doivent supporter. En .Net,
c'est natif, ils sont compatibles à la base.

Je suis peut être le seul à le penser, mais je continue d'être bluffé par
COM, et je suis déçu que Microsoft soit passé à .Net.
J'ai été élevé au Windows, donc je ne suis sans doute pas objectif. Je
trouve que les concepts derrière COM étaient tout bonnement (encore)
révolutionnaires (surtout à grande échelle dans un OS) et ils sont loin
d'avoir été exploités comme ils le méritent. Je trouve que Microsoft a eu
beaucoup d'audace d' intégrer une telle technologie.
Qu'est ce qu'on nous propose maintenant? Avec dot net: une usine à gaz, avec
nouveaux languages, nouveaux dialectes, une machine virtuelle (pas installée
sur toutes les machines), etc. Et on va vivre dessus pendant des années...
(très sincèrement: quel intérêt d'une machine virtuelle, pour exécuter une
application sur Windows???)

Je suis assez d'accord. Je suis aussi très attaché à mes habitudes
chèrement acquises. Conceptuellement je trouve .Net très intéressant,
mais dans la pratique, je suis plus nuancé. .Net corrige pas mal des
gros problèmes du développement natif/Win32, et c'est vraiment +
agréable et + simple. Mais c'est aussi + limité : on efface pas comme ça
20 ans d'évolution.

Ce que Microsoft aurait dû faire je pense, c'est simplifier la façon
d'écrire des composants COM, pour C++, pour C, et autres.

C'est ce qu'ils ont fait depuis longtemps. MFC/ATL, les assistants de
VC++, la directive #import, ... Et en VB c'est le langage roi en matière
de programmation COM. Automatiser Excel est un jeu d'enfant.
Mais tout ça ce sont des pansements qui viennent se coler au dessus de
Win32. En .Net y'a plus rien à panser. Maintenant, si le pansement te
convenait parfaitement, alors tu n'en voit pas l'utilité. Mais pour les
petits nouveaux à former, c'est quand même 2 belles étapes de gagner
(apprendre les problèmes, apprendre à les résoudres).

Aujourd'hui...
combien de languages vont pouvoir se permettre le passage à .Net...? C++ a
été dialectisé: en avait t'on vraiment besoin??
Bien sûr, COM ne disparait pas avec .Net, mais il va être marginalisé,
puisque les gens vont écrire du .Net plutôt que du COM.

Pour le C++, je trouve que MS a bien joué. Managed C++, techniquement
parlant, c'est un truc assez bluffant. Dans un environnement managé, tu
compiles et appelles du code natif sans te poser de questions, le
compilo gère tout en arrière plan. Par rapport à Java/JNI c'est vraiment
super.
Mais c'est pas parfait pout autant. La syntaxe est immonde. Managed C++
était juste là pour faciliter la migration de projets C++ natifs
existants vers .Net : c'est mieux que de tout recoder.
Maintenant on a C++/CLI, qui a plus d'ambition : être un langage à part
entière, capable de rivaliser avec C#. Là, pour le coup, je sais pas
trop ce que ça va donner.

Je crois que c'est beaucoup plus simple. MS avait besoin d'offrir une
nouvelle impulsion au développement sous Windows, et de rester celui qui
mène la dance. Je crois que c'est réussi.

Effectivement, il fallait proposer une alternative à Java, et ils ont
mélangé toutes leurs idées et technologies ensemble, pour nous sortir du
..Net.

Win32 est une API objet utilisée essentiellement via des langages de
programmation objet. Paradoxe dans tout ça : l'interface qui les
connecte est en C. Ca se défend parfaitement, mais c'est un fait. Cette
interface C native est pour le programmeur moyen plus une gêne qu'autre
chose. Quand tu y penses, c'est allucinant de ne pas pouvoir utiliser
dans un langage X un composant développé en un autre. Et même dans un
même langage comme C++, une dll VC++ ne peut pas être utilisée avec g++
(tu vois l'idée de ma remarque).

Donc le mélange et l'uniformisation ne me choque pas. Personnellement,
je trouve même que c'est la grande force de .Net.
Sauf que c'est encore un monde parallèle, un peu en marge. En ce qui
nous concerne, ça revient à jouer les colons.
Personnelement j'ai plutôt envie qu'elle s'impose toute seule (ou que
Microsoft s'en charge), plutôt que de me battre à justifier pourquoi il
faut installer le framework pour utiliser mon appli.

--
Aurélien Regat-Barrel

Aurelien Regat-Barrel <nospam.aregatba@yahoo.fr> writes:

Maintenant on a C++/CLI, qui a plus d'ambition : être un langage à part
entière, capable de rivaliser avec C#. Là, pour le coup, je sais pas trop
ce que ça va donner.

Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
exactement la meme utilite: servir d'interface entre du C++ et du
.NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
en faire un langage a succes: de l'homogeneite dans les concepts
utilises. Il melange les concepts de C++ et ceux de CLI. Il va
continuer a etre tiraille entre les deux.

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
exactement la meme utilite: servir d'interface entre du C++ et du
..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
en faire un langage a succes: de l'homogeneite dans les concepts
utilises. Il melange les concepts de C++ et ceux de CLI. Il va
continuer a etre tiraille entre les deux.

Tu appelles ça un manque d'homogeneite, ses concepteurs une force ;)
Question de point de vue sans doute.
C++/CLI est le seul à permettre le RAII et à offrir les templates en
plus des generics. Le dernier point a été défendu ici:
http://blogs.msdn.com/slippman/archive/2004/08/05/209606.aspx

Mais je suis d'accord que dans l'ensemble ça laisse perplexe. C'est ni
blanc ni noir, c'est gris...

Il m'avait semblé lire qu'une classe managée pourrait hériter d'un type
natif (sorte d'héritage privé). Ca aurait été une possibilité fabuleuse.
Mais j'ai du prendre mes désirs pour des réalités :-(

--
Aurélien Regat-Barrel

Aurelien Regat-Barrel <nospam.aregatba@yahoo.fr> writes:

Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
exactement la meme utilite: servir d'interface entre du C++ et du
..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
en faire un langage a succes: de l'homogeneite dans les concepts
utilises. Il melange les concepts de C++ et ceux de CLI. Il va
continuer a etre tiraille entre les deux.

Tu appelles ça un manque d'homogeneite, ses concepteurs une force ;)

Entre unification et confusion, il n'y a qu'une difference de point de
vue...

Je trouve qu'avoir deux modeles objets et deux modeles de genericites,
c'est un manque d'homogeneite -- et je pense que ce manque
d'homogeneite est consubstantiel a l'idee de C++/CLI --; quand en plus
ces modeles ne sont pas syntaxiquement bien distinct, ca releve pour
moi de la confusion -- la je ne crois pas que c'etait necessaire.

Question de point de vue sans doute. C++/CLI est le seul à
permettre le RAII et à offrir les templates en plus des generics.

Ada. Bien qu'a ma connaissance aucun compilateur Ada95 n'implemente
la genericite "partagee", la norme est soigneusement construite pour
la permettre. Certains compilateurs Ada83 avaient un pragma qui
permettait de passer d'un mode a l'autre sans changer la semantique.
On faisait le choix suivant l'importance relative de la compacite du
code/aspect bibliotheque sans generation de code et de la rapidite du
resultat (mais Ada83 n'avait pas l'equivalent de
constructeur/destructeur).

Le dernier point a été défendu ici:
http://blogs.msdn.com/slippman/archive/2004/08/05/209606.aspx

J'irai voir quand j'aurai le temps.

Il m'avait semblé lire qu'une classe managée pourrait hériter d'un type
natif (sorte d'héritage privé). Ca aurait été une possibilité fabuleuse.
Mais j'ai du prendre mes désirs pour des réalités :-(

Je n'ose pas imaginer le resultat.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Aurelien Regat-Barrel <nospam.aregatba@yahoo.fr> writes:

| > Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
| > exactement la meme utilite: servir d'interface entre du C++ et du
| > ..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
| > en faire un langage a succes: de l'homogeneite dans les concepts
| > utilises. Il melange les concepts de C++ et ceux de CLI. Il va
| > continuer a etre tiraille entre les deux.
|
| Tu appelles ça un manque d'homogeneite, ses concepteurs une force ;)
| Question de point de vue sans doute.
| C++/CLI est le seul à permettre le RAII et à offrir les templates en
| plus des generics.

???

| Le dernier point a été défendu ici:
| http://blogs.msdn.com/slippman/archive/2004/08/05/209606.aspx

et lire également

http://public.research.att.com/~bs/bs_faq.html#CppCLI

-- Gaby

| C++/CLI est le seul à permettre le RAII et à offrir les templates en
| plus des generics.

???

"C++/CLI est le seul (*langage .Net*) à permettre le RAII et à offrir
les templates"

désolé pour cet oubli

et lire également

http://public.research.att.com/~bs/bs_faq.html#CppCLI

Haaa, enfin un avis extérieur sur le sujet. Merci pour le lien.

--
Aurélien Regat-Barrel