Développant en C++ (outils Microsoft sous Windows) depuis de nombreuses
années, je suis actuellement en recherche de poste (ingénieur de
développement) à 41 ans, et j'ai beaucoup de mal à trouver.
Dois-je en cnclure que le développement en C++ est en voie de
disparition (Java semble avoir la cote en ce moment), que je suis "trop
vieux" pour ça (il y a pourtant des développeurs seniors), ou que le
développement informatique est désormais suffisament "offshorisé" pour
limiter les recrutements en région parisienne ?
Et en prime, on se retrouve à gérer des trucs pour lesquels on n'a pas forcément d'atomes crochus -- ne serait-ce que toute la partie "comptabilité". À moins qu'on gagne vraiment très bien, et qu'on puisse tout sous-traiter.
Dans la pratique, il faut sous-traiter la comptabilité. Il faut aussi payer des charges sociaux soi-même, et un tas d'autres choses. En gros, pour avoir à peu près le même niveau de vie, ton taux journalier doit valoir à peu près ton salaire brut divisé par 7 ; sinon, tu es perdant.
(Ceci dit : la comptabilité ne me coûte qu'environ 700 Euros par ans. Peanuts, à côté de l'URSSAF, la sécurité sociale, la caisse de retraite...)
Une partie du problème, c'est que les entreprises ne savent pas bien évaluer les candidats. Il faut donc qu'elles aient une sortie si le candidat accepté ne fait pas l'affaire. Et c'est beaucoup plus facile à trouver quelque chose d'autre dans la boîte pour un type peu payé.
Note qu'il y a une autre méthode : un CDD de six mois, qui débouche sur un CDI si le candidat s'avère compétent, ou sur rien sinon.
Par exemple. Et ce n'est pas inconnu, les cas où le préstataire finit par entrer en fixe.
Dans les deux cas, il faut un DRH un peu souple.
Alors, le service du personel procure les n ingenieurs les moins chers qu'il peut.
On revient sur le problème ci-dessus : la personne chargée du recrutement ne comprend pas grand-chose aux besoins de l'employeur, et encore moins aux capacités des candidats.
En effet. Alors, ils appliquent les règles qu'on utilise pour le choix des fournisseurs des boulons et des choses pareilles.
Une des raisons que g++ s'est aussi bien répandu, c'est qu'on peut l'obtenir sans passer par le service achats. Une des raisons que l'utilisation des préstataires se répand, c'est qu'on peut obtenir du personel sans passer par le service du personel. Dans les deux cas, on a souvent affaire à des services administratifs qui ne comprenent pas la contexte.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 11 Jan 2006 04:23:23 -0800, "kanze" <kanze@gabi-soft.fr>:
-- Devenir indépendant. La risque n'est pas peu
Et en prime, on se retrouve à gérer des trucs pour lesquels on
n'a pas forcément d'atomes crochus -- ne serait-ce que toute
la partie "comptabilité". À moins qu'on gagne vraiment très
bien, et qu'on puisse tout sous-traiter.
Dans la pratique, il faut sous-traiter la comptabilité. Il faut
aussi payer des charges sociaux soi-même, et un tas d'autres
choses. En gros, pour avoir à peu près le même niveau de vie,
ton taux journalier doit valoir à peu près ton salaire brut
divisé par 7 ; sinon, tu es perdant.
(Ceci dit : la comptabilité ne me coûte qu'environ 700 Euros par
ans. Peanuts, à côté de l'URSSAF, la sécurité sociale, la caisse
de retraite...)
Une partie du problème, c'est que les entreprises ne savent
pas bien évaluer les candidats. Il faut donc qu'elles aient
une sortie si le candidat accepté ne fait pas l'affaire. Et
c'est beaucoup plus facile à trouver quelque chose d'autre
dans la boîte pour un type peu payé.
Note qu'il y a une autre méthode : un CDD de six mois, qui
débouche sur un CDI si le candidat s'avère compétent, ou sur
rien sinon.
Par exemple. Et ce n'est pas inconnu, les cas où le préstataire
finit par entrer en fixe.
Dans les deux cas, il faut un DRH un peu souple.
Alors, le service du
personel procure les n ingenieurs les moins chers qu'il peut.
On revient sur le problème ci-dessus : la personne chargée du
recrutement ne comprend pas grand-chose aux besoins de
l'employeur, et encore moins aux capacités des candidats.
En effet. Alors, ils appliquent les règles qu'on utilise pour le
choix des fournisseurs des boulons et des choses pareilles.
Une des raisons que g++ s'est aussi bien répandu, c'est qu'on
peut l'obtenir sans passer par le service achats. Une des
raisons que l'utilisation des préstataires se répand, c'est
qu'on peut obtenir du personel sans passer par le service du
personel. Dans les deux cas, on a souvent affaire à des services
administratifs qui ne comprenent pas la contexte.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Et en prime, on se retrouve à gérer des trucs pour lesquels on n'a pas forcément d'atomes crochus -- ne serait-ce que toute la partie "comptabilité". À moins qu'on gagne vraiment très bien, et qu'on puisse tout sous-traiter.
Dans la pratique, il faut sous-traiter la comptabilité. Il faut aussi payer des charges sociaux soi-même, et un tas d'autres choses. En gros, pour avoir à peu près le même niveau de vie, ton taux journalier doit valoir à peu près ton salaire brut divisé par 7 ; sinon, tu es perdant.
(Ceci dit : la comptabilité ne me coûte qu'environ 700 Euros par ans. Peanuts, à côté de l'URSSAF, la sécurité sociale, la caisse de retraite...)
Une partie du problème, c'est que les entreprises ne savent pas bien évaluer les candidats. Il faut donc qu'elles aient une sortie si le candidat accepté ne fait pas l'affaire. Et c'est beaucoup plus facile à trouver quelque chose d'autre dans la boîte pour un type peu payé.
Note qu'il y a une autre méthode : un CDD de six mois, qui débouche sur un CDI si le candidat s'avère compétent, ou sur rien sinon.
Par exemple. Et ce n'est pas inconnu, les cas où le préstataire finit par entrer en fixe.
Dans les deux cas, il faut un DRH un peu souple.
Alors, le service du personel procure les n ingenieurs les moins chers qu'il peut.
On revient sur le problème ci-dessus : la personne chargée du recrutement ne comprend pas grand-chose aux besoins de l'employeur, et encore moins aux capacités des candidats.
En effet. Alors, ils appliquent les règles qu'on utilise pour le choix des fournisseurs des boulons et des choses pareilles.
Une des raisons que g++ s'est aussi bien répandu, c'est qu'on peut l'obtenir sans passer par le service achats. Une des raisons que l'utilisation des préstataires se répand, c'est qu'on peut obtenir du personel sans passer par le service du personel. Dans les deux cas, on a souvent affaire à des services administratifs qui ne comprenent pas la contexte.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Aurelien Regat-Barrel wrote:
On 11 Jan 2006 04:06:45 -0800, "kanze" :
Sinon, de l'expérience .NET est aussi très démandée.
C'est marrant, j'ai récemment appelé un copain parti travailler à Paris (je suis en province) et il m'a dit que les offres .Net explosaient, qu'il fallait que je m'y remette car C++ ça allait disparaître...
Sauf que la plupart des projets que je connais en .NET utilise le C++, et non seulement C#. C'est un C++ un peu spécial, d'accord, mais c'est quand même du C++.
Est-ce un effet de mode, d'après toi ?
Personnellement, j'ai toujours pensé que .Net ne décolerait pas plus que ça tant que Longhorn/Vista ne serait pas là. C'est prévu pour cette année...
Ce qui est sûr, c'est que la plupart des boîtes veulent faire au moins un projet en .NET, ne serait-ce que pour l'évaluer. Et qu'elles n'en ont pas expértisent internes, pour des raisons évidentes.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aurelien Regat-Barrel wrote:
On 11 Jan 2006 04:06:45 -0800, "kanze" <kanze@gabi-soft.fr>:
Sinon, de l'expérience .NET est aussi très démandée.
C'est marrant, j'ai récemment appelé un copain parti
travailler à Paris (je suis en province) et il m'a dit que les
offres .Net explosaient, qu'il fallait que je m'y remette car
C++ ça allait disparaître...
Sauf que la plupart des projets que je connais en .NET utilise
le C++, et non seulement C#. C'est un C++ un peu spécial,
d'accord, mais c'est quand même du C++.
Est-ce un effet de mode, d'après toi ?
Personnellement, j'ai toujours pensé que .Net ne décolerait
pas plus que ça tant que Longhorn/Vista ne serait pas là.
C'est prévu pour cette année...
Ce qui est sûr, c'est que la plupart des boîtes veulent faire au
moins un projet en .NET, ne serait-ce que pour l'évaluer. Et
qu'elles n'en ont pas expértisent internes, pour des raisons
évidentes.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour
une réussite à peu près comme Java : il y aura certaines
catégories d'applications où il servira beaucoup, mais il serait
assez peu utilisé en dehors de ces catégories.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sinon, de l'expérience .NET est aussi très démandée.
C'est marrant, j'ai récemment appelé un copain parti travailler à Paris (je suis en province) et il m'a dit que les offres .Net explosaient, qu'il fallait que je m'y remette car C++ ça allait disparaître...
Sauf que la plupart des projets que je connais en .NET utilise le C++, et non seulement C#. C'est un C++ un peu spécial, d'accord, mais c'est quand même du C++.
Est-ce un effet de mode, d'après toi ?
Personnellement, j'ai toujours pensé que .Net ne décolerait pas plus que ça tant que Longhorn/Vista ne serait pas là. C'est prévu pour cette année...
Ce qui est sûr, c'est que la plupart des boîtes veulent faire au moins un projet en .NET, ne serait-ce que pour l'évaluer. Et qu'elles n'en ont pas expértisent internes, pour des raisons évidentes.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
John Deuf
Sinon, de l'expérience .NET est aussi très démandée.
Est-ce un effet de mode, d'après toi ?
.Net remplacera l'API win32 a terme (plus précisément, l'api WinFX qui contient notamment .Net remplacera Win32). http://msdn.microsoft.com/winfx/ Donc pour tout développement Windows, il y faudra une expérience en .Net.
Sinon, de l'expérience .NET est aussi très démandée.
Est-ce un effet de mode, d'après toi ?
.Net remplacera l'API win32 a terme (plus précisément, l'api WinFX
qui contient notamment .Net remplacera Win32).
http://msdn.microsoft.com/winfx/
Donc pour tout développement Windows, il y faudra une expérience en
.Net.
Sinon, de l'expérience .NET est aussi très démandée.
Est-ce un effet de mode, d'après toi ?
.Net remplacera l'API win32 a terme (plus précisément, l'api WinFX qui contient notamment .Net remplacera Win32). http://msdn.microsoft.com/winfx/ Donc pour tout développement Windows, il y faudra une expérience en .Net.
John Deuf
Sauf que la plupart des projets que je connais en .NET utilise le C++, et non seulement C#. C'est un C++ un peu spécial, d'accord, mais c'est quand même du C++.
Mieux que ça, on peut mélanger le code C++ managed (celui que tu appelles "spécial") et le C++ classique. La solution la plus courante c'est de faire l'interface utilisateur avec .Net et du C++ managed, puis de faire le reste de l'application avec du C++ classique natif. Et d'après ce que je sais, il n'y a qu'avec C++ que c'est possible (pas C# ni VB.Net). Donc .Net ce n'est surement pas la fin du C++.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies. En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un développement beaucoup plus important que Java (si tenté qu'on puisse comparer .Net et Java).
Sauf que la plupart des projets que je connais en .NET utilise
le C++, et non seulement C#. C'est un C++ un peu spécial,
d'accord, mais c'est quand même du C++.
Mieux que ça, on peut mélanger le code C++ managed (celui que tu
appelles "spécial") et le C++ classique. La solution la plus courante
c'est de faire l'interface utilisateur avec .Net et du C++ managed,
puis de faire le reste de l'application avec du C++ classique natif. Et
d'après ce que je sais, il n'y a qu'avec C++ que c'est possible (pas
C# ni VB.Net).
Donc .Net ce n'est surement pas la fin du C++.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour
une réussite à peu près comme Java : il y aura certaines
catégories d'applications où il servira beaucoup, mais il serait
assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système
d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour
imposer ses technologies.
En l'occurence, à terme, pour programmer une application Windows, il
sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un
développement beaucoup plus important que Java (si tenté qu'on puisse
comparer .Net et Java).
Sauf que la plupart des projets que je connais en .NET utilise le C++, et non seulement C#. C'est un C++ un peu spécial, d'accord, mais c'est quand même du C++.
Mieux que ça, on peut mélanger le code C++ managed (celui que tu appelles "spécial") et le C++ classique. La solution la plus courante c'est de faire l'interface utilisateur avec .Net et du C++ managed, puis de faire le reste de l'application avec du C++ classique natif. Et d'après ce que je sais, il n'y a qu'avec C++ que c'est possible (pas C# ni VB.Net). Donc .Net ce n'est surement pas la fin du C++.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies. En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un développement beaucoup plus important que Java (si tenté qu'on puisse comparer .Net et Java).
John Deuf
Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il fait un peu plus de bugs.
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.
Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il
fait un peu plus de bugs.
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.
Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il fait un peu plus de bugs.
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.
Aurelien Regat-Barrel
Sauf que la plupart des projets que je connais en .NET utilise le C++, et non seulement C#. C'est un C++ un peu spécial, d'accord, mais c'est quand même du C++.
Mieux que ça, on peut mélanger le code C++ managed (celui que tu appelles "spécial") et le C++ classique. La solution la plus courante c'est de faire l'interface utilisateur avec .Net et du C++ managed, puis de faire le reste de l'application avec du C++ classique natif. Et d'après ce que je sais, il n'y a qu'avec C++ que c'est possible (pas C# ni VB.Net). Donc .Net ce n'est surement pas la fin du C++.
La Managed C++ a disparu et est remplacé par le C++/CLI depuis .Net 2. MC++ servait surtout de pont entre C++ natif et .Net (syntaxe immonde), C++/CLI se veut plus comme un challenger à part entière. Il a ses atouts par rapport aux autres (RAII, templates,...). Mais c'est bien du C++/CLI, un "autre chose" que du C++. Peut être que c'est le début d'un fork un peu comme "C with classes" a forké du langage C.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies.
Je suis assez d'accord avec toi sur ce point. Je ne suis pas sûr que .Net suive le même chemin que Java, parce que les moyens de Microsoft sont bien supérieurs. Il suffit de comparer la vitesse d'évolution des 2 technologies.
En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un développement beaucoup plus important que Java (si tenté qu'on puisse comparer .Net et Java).
Ca c'est pas encore fait. XP supporte toujours MS-DOS, et les nouveautés dans Longhorn ne devaient être dispo qu'en .Net. Et bien elle sont aussi dispo en Win32 (en partie du moins), et les anciennes applis VB continueront à tourner sur Vista. L'avantage de MS c'est qu'ils ont le Java OS : .Net sera bientôt dispo par défaut sous Windows (plus de VM/framework à installer), et en plus ce sera une techno native (accès direct aux fonctionnalités propres à l'OS). Donc, sous Windows du moins, il est évident que ça va raffler la mise par rapport à Java. De là à faire disparaître le C++ natif, y'a quand même une sacré étape.
-- Aurélien Regat-Barrel
Sauf que la plupart des projets que je connais en .NET utilise
le C++, et non seulement C#. C'est un C++ un peu spécial,
d'accord, mais c'est quand même du C++.
Mieux que ça, on peut mélanger le code C++ managed (celui que tu
appelles "spécial") et le C++ classique. La solution la plus courante
c'est de faire l'interface utilisateur avec .Net et du C++ managed,
puis de faire le reste de l'application avec du C++ classique natif. Et
d'après ce que je sais, il n'y a qu'avec C++ que c'est possible (pas
C# ni VB.Net).
Donc .Net ce n'est surement pas la fin du C++.
La Managed C++ a disparu et est remplacé par le C++/CLI depuis .Net 2.
MC++ servait surtout de pont entre C++ natif et .Net (syntaxe immonde),
C++/CLI se veut plus comme un challenger à part entière. Il a ses atouts
par rapport aux autres (RAII, templates,...). Mais c'est bien du
C++/CLI, un "autre chose" que du C++. Peut être que c'est le début d'un
fork un peu comme "C with classes" a forké du langage C.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour
une réussite à peu près comme Java : il y aura certaines
catégories d'applications où il servira beaucoup, mais il serait
assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système
d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour
imposer ses technologies.
Je suis assez d'accord avec toi sur ce point. Je ne suis pas sûr que
.Net suive le même chemin que Java, parce que les moyens de Microsoft
sont bien supérieurs. Il suffit de comparer la vitesse d'évolution des 2
technologies.
En l'occurence, à terme, pour programmer une application Windows, il
sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un
développement beaucoup plus important que Java (si tenté qu'on puisse
comparer .Net et Java).
Ca c'est pas encore fait. XP supporte toujours MS-DOS, et les nouveautés
dans Longhorn ne devaient être dispo qu'en .Net. Et bien elle sont aussi
dispo en Win32 (en partie du moins), et les anciennes applis VB
continueront à tourner sur Vista.
L'avantage de MS c'est qu'ils ont le Java OS : .Net sera bientôt dispo
par défaut sous Windows (plus de VM/framework à installer), et en plus
ce sera une techno native (accès direct aux fonctionnalités propres à
l'OS). Donc, sous Windows du moins, il est évident que ça va raffler la
mise par rapport à Java.
De là à faire disparaître le C++ natif, y'a quand même une sacré étape.
Sauf que la plupart des projets que je connais en .NET utilise le C++, et non seulement C#. C'est un C++ un peu spécial, d'accord, mais c'est quand même du C++.
Mieux que ça, on peut mélanger le code C++ managed (celui que tu appelles "spécial") et le C++ classique. La solution la plus courante c'est de faire l'interface utilisateur avec .Net et du C++ managed, puis de faire le reste de l'application avec du C++ classique natif. Et d'après ce que je sais, il n'y a qu'avec C++ que c'est possible (pas C# ni VB.Net). Donc .Net ce n'est surement pas la fin du C++.
La Managed C++ a disparu et est remplacé par le C++/CLI depuis .Net 2. MC++ servait surtout de pont entre C++ natif et .Net (syntaxe immonde), C++/CLI se veut plus comme un challenger à part entière. Il a ses atouts par rapport aux autres (RAII, templates,...). Mais c'est bien du C++/CLI, un "autre chose" que du C++. Peut être que c'est le début d'un fork un peu comme "C with classes" a forké du langage C.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies.
Je suis assez d'accord avec toi sur ce point. Je ne suis pas sûr que .Net suive le même chemin que Java, parce que les moyens de Microsoft sont bien supérieurs. Il suffit de comparer la vitesse d'évolution des 2 technologies.
En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un développement beaucoup plus important que Java (si tenté qu'on puisse comparer .Net et Java).
Ca c'est pas encore fait. XP supporte toujours MS-DOS, et les nouveautés dans Longhorn ne devaient être dispo qu'en .Net. Et bien elle sont aussi dispo en Win32 (en partie du moins), et les anciennes applis VB continueront à tourner sur Vista. L'avantage de MS c'est qu'ils ont le Java OS : .Net sera bientôt dispo par défaut sous Windows (plus de VM/framework à installer), et en plus ce sera une techno native (accès direct aux fonctionnalités propres à l'OS). Donc, sous Windows du moins, il est évident que ça va raffler la mise par rapport à Java. De là à faire disparaître le C++ natif, y'a quand même une sacré étape.
-- Aurélien Regat-Barrel
Fabien LE LEZ
On 13 Jan 2006 02:06:24 -0800, "John Deuf" :
En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX).
Pas forcément directement.
L'API Win32 est prévue pour le C, mais il existe des encapsulations C++ qui nous évitent de trop patauger dans cette API. D'ailleurs, certaines encapsulations (Qt et wxWidgets notamment) sont basées sur l'idée d'avoir une interface commune à plusieurs API (MacOSX, Win32, etc.).
L'API .Net est prévue pour le C#, mais si elle devient obligatoire, il est probable qu'il existera des bibliothèques d'encapsulation pour l'utiliser avec C++. Après tout, ce n'est jamais qu'un portage supplémentaire pour Qt et wxWidgets.
On 13 Jan 2006 02:06:24 -0800, "John Deuf" <franvalent@free.fr>:
En l'occurence, à terme, pour programmer une application Windows, il
sera obligatoire de passer par .Net (WinFX).
Pas forcément directement.
L'API Win32 est prévue pour le C, mais il existe des encapsulations
C++ qui nous évitent de trop patauger dans cette API. D'ailleurs,
certaines encapsulations (Qt et wxWidgets notamment) sont basées sur
l'idée d'avoir une interface commune à plusieurs API (MacOSX, Win32,
etc.).
L'API .Net est prévue pour le C#, mais si elle devient obligatoire, il
est probable qu'il existera des bibliothèques d'encapsulation pour
l'utiliser avec C++. Après tout, ce n'est jamais qu'un portage
supplémentaire pour Qt et wxWidgets.
En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX).
Pas forcément directement.
L'API Win32 est prévue pour le C, mais il existe des encapsulations C++ qui nous évitent de trop patauger dans cette API. D'ailleurs, certaines encapsulations (Qt et wxWidgets notamment) sont basées sur l'idée d'avoir une interface commune à plusieurs API (MacOSX, Win32, etc.).
L'API .Net est prévue pour le C#, mais si elle devient obligatoire, il est probable qu'il existera des bibliothèques d'encapsulation pour l'utiliser avec C++. Après tout, ce n'est jamais qu'un portage supplémentaire pour Qt et wxWidgets.
Fabien LE LEZ
On 13 Jan 2006 02:10:46 -0800, "John Deuf" :
Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il fait un peu plus de bugs.
[...] on peut pas trouver de boulot si on a pas au moins 2 ans d'expérience.
2 ans d'expérience, en C++, c'est bien être "quasi-débutant".
On 13 Jan 2006 02:10:46 -0800, "John Deuf" <franvalent@free.fr>:
Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il
fait un peu plus de bugs.
[...] on peut pas trouver de boulot si on a pas au moins 2 ans
d'expérience.
2 ans d'expérience, en C++, c'est bien être "quasi-débutant".
Les entreprises préfèrent un quasi débutant (deux fois moins cher) même s'il fait un peu plus de bugs.
[...] on peut pas trouver de boulot si on a pas au moins 2 ans d'expérience.
2 ans d'expérience, en C++, c'est bien être "quasi-débutant".
loufoque
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Bon, les deux sont faits pour le RAD, ce qui permet de faire des projets simples rapidement. La différence entre les deux étant que .NET est plus focalisé sur Windows.
Pour les applications plus critiques, le code non automagique en C++ reste la référence. Enfin encore faut-il pouvoir trouver des projets d'envergure.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour
une réussite à peu près comme Java : il y aura certaines
catégories d'applications où il servira beaucoup, mais il serait
assez peu utilisé en dehors de ces catégories.
Bon, les deux sont faits pour le RAD, ce qui permet de faire des projets
simples rapidement.
La différence entre les deux étant que .NET est plus focalisé sur Windows.
Pour les applications plus critiques, le code non automagique en C++
reste la référence.
Enfin encore faut-il pouvoir trouver des projets d'envergure.
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Bon, les deux sont faits pour le RAD, ce qui permet de faire des projets simples rapidement. La différence entre les deux étant que .NET est plus focalisé sur Windows.
Pour les applications plus critiques, le code non automagique en C++ reste la référence. Enfin encore faut-il pouvoir trouver des projets d'envergure.
loufoque
Donc pour tout développement Windows, il y faudra une expérience en .Net.
Pas forcément, non. Actuellement, je fais des applications pour windows et je ne connais rien à l'api win32.
Donc pour tout développement Windows, il y faudra une expérience en
.Net.
Pas forcément, non.
Actuellement, je fais des applications pour windows et je ne connais
rien à l'api win32.
