Windiws Longhorn: le C n est t'il plus le langage de prédilection de programmation pour atteindre le systéme ?
53 réponses
Nospam999
Bonjour bonsoir,
Dans Pc Expert de septembre 2003 Olivier Gaussin dit à propos de .Net "Le
framework repose sur Windows mais on n'est pas loin d'arriver à la situation
inverse , où Windows reposera sur le framework. En effet, le prochain
système d'exploitation de Microsoft, Longhorn, qui n'arrivera pas avant
2004, officialisera . Net comme API dans certains domaines. Exit les Api
Win32: Il faudra nécessairement passer par .Net pour accéder au service du
systèmes"
Cela me fait peur. En effet, je commence à faire de la programmation sous
Windows avec du c avec les Api 32 .
1- Avez vous des informations plus précises ?
2- Est ce vrai ?
3- Dois je arrêter et changer de système si je veux utiliser le C ?
Merci pour de répondre à un véritable débutant.
P.S: 1- J'ai fait une citation un peu longue mais c'était uniquement pour
être
clair. Milles excuses si cela peut gêner quelqu'un.
2- On m'a dit que le cross posting c'est mal: je cherche simplement à
"toucher des populations différentes ( c'est important pour moi...car je
sens que j'y passe du temps) c'est promis je ne recommencerai plus.....
"Arnaud Debaene" wrote in message news:3f674f6c$0$20155$
Arnold McDonald (AMcD) wrote: > Arnaud Debaene wrote: > >> Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans >> l'absolu, ce ne sont pas de bonnes raison mais il faut rester >> pragmatique : >> - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ >> compétents. > > Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ? Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)
il vaut mieux que cela soit vous qui le dites quand même :-)
VB
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:3f674f6c$0$20155$626a54ce@news.free.fr...
Arnold McDonald (AMcD) wrote:
> Arnaud Debaene wrote:
>
>> Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
>> l'absolu, ce ne sont pas de bonnes raison mais il faut rester
>> pragmatique :
>> - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
>> compétents.
>
> Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ?
Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)
il vaut mieux que cela soit vous qui le dites quand même :-)
"Arnaud Debaene" wrote in message news:3f674f6c$0$20155$
Arnold McDonald (AMcD) wrote: > Arnaud Debaene wrote: > >> Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans >> l'absolu, ce ne sont pas de bonnes raison mais il faut rester >> pragmatique : >> - complexité du C++ : Il n'y a pas beaucoup de programmeurs C++ >> compétents. > > Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ? Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)
il vaut mieux que cela soit vous qui le dites quand même :-)
VB
Arnaud Debaene
wrote:
(d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne, portable???)
Si on parle de GUI, il y a WxWindows.
il est plus simple de programmer (mal) en C# qu'en C++...
Yep.
et je pense qu'il est plus simple de programmer correctement en C# qu'en C++.
Là j'en suis moins sûr : je vois au moins 2 gros défauts à C# pour des développeurs "avancés" : - Le modèle de compilation du C# rend les (re)compilations pour de très gros projets difficile à gérer et potentiellement très longs (même si le compilo est rapide). Dans certains contextes (recompilation centralisée des modifs faites par toute l'équipe chaque nuit par exemple), çà peut être prohibitif. - Impossibilité de garantir une libération automatique des ressources non managées sans se reposer sur le code client (il y a bien IDispose, mais c'est un pis-aller).
J'ajouterais que pour l'instant, on manque de recul et d'expérience sur la "bonne" façon de programer en C# : On a pas encore l'équivalent d'un Herb Stutter ou d'un Andrei Alexandrescu en C#.
.. en tous cas y'a déjà pas mal d'erreur que tu ne pourras pas faire en C#...
Oui, mais certaines choses gérables en C++ (libération des ressources non managées en autres) ne le sont pas en C#.
Arnaud
poubelle@alrj.org wrote:
(d'ailleurs qu'est ce qui existe comme framework
C++ élégant, moderne, portable???)
Si on parle de GUI, il y a WxWindows.
il est plus simple de programmer (mal) en C#
qu'en C++...
Yep.
et je pense qu'il est plus simple de programmer
correctement en C# qu'en C++.
Là j'en suis moins sûr : je vois au moins 2 gros défauts à C# pour des
développeurs "avancés" :
- Le modèle de compilation du C# rend les (re)compilations pour de très gros
projets difficile à gérer et potentiellement très longs (même si le compilo
est rapide). Dans certains contextes (recompilation centralisée des modifs
faites par toute l'équipe chaque nuit par exemple), çà peut être prohibitif.
- Impossibilité de garantir une libération automatique des ressources non
managées sans se reposer sur le code client (il y a bien IDispose, mais
c'est un pis-aller).
J'ajouterais que pour l'instant, on manque de recul et d'expérience sur la
"bonne" façon de programer en C# : On a pas encore l'équivalent d'un Herb
Stutter ou d'un Andrei Alexandrescu en C#.
.. en tous cas y'a déjà pas mal d'erreur
que tu ne pourras pas faire en C#...
Oui, mais certaines choses gérables en C++ (libération des ressources non
managées en autres) ne le sont pas en C#.
(d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne, portable???)
Si on parle de GUI, il y a WxWindows.
il est plus simple de programmer (mal) en C# qu'en C++...
Yep.
et je pense qu'il est plus simple de programmer correctement en C# qu'en C++.
Là j'en suis moins sûr : je vois au moins 2 gros défauts à C# pour des développeurs "avancés" : - Le modèle de compilation du C# rend les (re)compilations pour de très gros projets difficile à gérer et potentiellement très longs (même si le compilo est rapide). Dans certains contextes (recompilation centralisée des modifs faites par toute l'équipe chaque nuit par exemple), çà peut être prohibitif. - Impossibilité de garantir une libération automatique des ressources non managées sans se reposer sur le code client (il y a bien IDispose, mais c'est un pis-aller).
J'ajouterais que pour l'instant, on manque de recul et d'expérience sur la "bonne" façon de programer en C# : On a pas encore l'équivalent d'un Herb Stutter ou d'un Andrei Alexandrescu en C#.
.. en tous cas y'a déjà pas mal d'erreur que tu ne pourras pas faire en C#...
Oui, mais certaines choses gérables en C++ (libération des ressources non managées en autres) ne le sont pas en C#.
Arnaud
Arnaud Debaene wrote:
wrote: > (d'ailleurs qu'est ce qui existe comme framework > C++ élégant, moderne, portable???) Si on parle de GUI, il y a WxWindows.
Le prob est que ça ne fait "que" la GUI, si tu veux gérer des bd, de l'xml, un chtit peu de réseau, une GUI windows et une interface web, tu te retrouves à accumuler les libs :-/ (et faut en trouver de bonne portable, s'adapter, s'assurer qu'elles fonctionnent entre elles, etc...).
> et je pense qu'il est plus simple de programmer > correctement en C# qu'en C++. Là j'en suis moins sûr : je vois au moins 2 gros défauts à C# pour des développeurs "avancés" : - Le modèle de compilation du C# rend les (re)compilations pour de très gros projets difficile à gérer et potentiellement très longs (même si le compilo est rapide). Dans certains contextes (recompilation centralisée des modifs faites par toute l'équipe chaque nuit par exemple), çà peut être prohibitif.
Là je suis d'accord, cependant on commence à voir apparaitre des solutions de compilations (hippo.net par exemple). Mais j'avoue ne pas vraiment d'expérience dans ce domaine, je n'ai pas de gros projet C#, et j'avoue aussi ne jamais avoir joué avec de vrai gros projet C++, naivement je me dis pourtant que c'est "gérable", le framework est en grande partie du C# et il me semble qu'on peut le qualifier de "gros projet".
Cependant, je reconnais volontier que le côté "magique" de la gestion des références de .NET peut rapidement mené à de longues compilations, mais en général, une bonne découpe en dll résoudra cela (et ça c'est un gros plus par rapport à Win32, pouvoir exposer des classes de façon vraiment transparente via une dll...).
- Impossibilité de garantir une libération automatique des ressources non managées sans se reposer sur le code client (il y a bien IDispose, mais c'est un pis-aller).
Oui et non, en fait le problème du garbage collector, c'est qu'on le présente comme un "il ne faut pas gérer la mémoire, c'est fait pour toi", ce qui n'est évidemment pas le cas! Le C# offre quand même "using" qui permet d'être relativement propre. En effet c'est "du code client", mais vu l'utilisation, ça revient plus à une "autre façon de déclarer une variable", un peu comme la gestion des block en C++ qui permet de contrôler le moment ou le destructeur d'une variable automatique sera appelé...
Si on regarde le problème de plus prêt, quels sont les resources non managés critiques? - Les fichiers, il faut alors appelé "Close" (ou using), en C++ on peut le faire grâce au destructeur, c'est vrai que c'est une étape en plus. - Les connexions réseaux, même genre de délire. - Les bases de données: toujours pareil, mais le connection pooling "automatique" de .NET vient aider la dedans... l'approche déconnectée aussi. - La mémoire: le garbage collector fait relativement bien son boulot, il faut juste penser à ce qui reste visible (en général remplace un "delete machin" en "machin=null" est une bonne idée ;). Il existe aussi quelques astuces (weak references par exemple) permettant d'avoir un contrôle plus fin. Pour la gestion "avancée" par contre (genre memory mapped file), c'est moins drôle... - Je dois surement, vu l'heure oublier quelques trucs important, mais ça ne me vient pas en tête ;)
J'ajouterais que pour l'instant, on manque de recul et d'expérience sur la "bonne" façon de programer en C# : On a pas encore l'équivalent d'un Herb Stutter ou d'un Andrei Alexandrescu en C#.
Là on est bien d'accord, cependant, la aussi .NET aide un petit peu: y'a déjà une série de convention existante, en C++ c'est assez difficile de trouver une cohérence... cependant, le problème reste toujours, on peut trouvé des lib .NET qui ne les respecte pas, on peut trouver un design différent, etc...
> .. en tous cas y'a déjà pas mal d'erreur > que tu ne pourras pas faire en C#... Oui, mais certaines choses gérables en C++ (libération des ressources non managées en autres) ne le sont pas en C#.
Via "using" et un code propre relativement, tu te retrouves en gros avec un équivalent des variables automatiques, il y'a aussi le "finally" qui sauve souvent la mise... évidemment, il reste le défaut qu'un développeur peut oublier tout cela, et son programme "fonctionnera" (avec un working set de 200Mo ;).
En bref: vivement les methodes anonymes, les generics et les enumerator! ;)
poubelle@alrj.org wrote:
> (d'ailleurs qu'est ce qui existe comme framework
> C++ élégant, moderne, portable???)
Si on parle de GUI, il y a WxWindows.
Le prob est que ça ne fait "que" la GUI, si tu veux gérer des bd, de
l'xml, un chtit peu de réseau, une GUI windows et une interface web, tu
te retrouves à accumuler les libs :-/ (et faut en trouver de bonne
portable, s'adapter, s'assurer qu'elles fonctionnent entre elles,
etc...).
> et je pense qu'il est plus simple de programmer
> correctement en C# qu'en C++.
Là j'en suis moins sûr : je vois au moins 2 gros défauts à C# pour des
développeurs "avancés" : - Le modèle de compilation du C# rend les
(re)compilations pour de très gros projets difficile à gérer et
potentiellement très longs (même si le compilo est rapide). Dans
certains contextes (recompilation centralisée des modifs faites par
toute l'équipe chaque nuit par exemple), çà peut être prohibitif.
Là je suis d'accord, cependant on commence à voir apparaitre des
solutions de compilations (hippo.net par exemple). Mais j'avoue ne pas
vraiment d'expérience dans ce domaine, je n'ai pas de gros projet C#,
et j'avoue aussi ne jamais avoir joué avec de vrai gros projet C++,
naivement je me dis pourtant que c'est "gérable", le framework est en
grande partie du C# et il me semble qu'on peut le qualifier de "gros
projet".
Cependant, je reconnais volontier que le côté "magique" de la gestion
des références de .NET peut rapidement mené à de longues compilations,
mais en général, une bonne découpe en dll résoudra cela (et ça c'est un
gros plus par rapport à Win32, pouvoir exposer des classes de façon
vraiment transparente via une dll...).
- Impossibilité de garantir une libération automatique des ressources
non managées sans se reposer sur le code client (il y a bien IDispose,
mais c'est un pis-aller).
Oui et non, en fait le problème du garbage collector, c'est qu'on le
présente comme un "il ne faut pas gérer la mémoire, c'est fait pour
toi", ce qui n'est évidemment pas le cas! Le C# offre quand même
"using" qui permet d'être relativement propre. En effet c'est "du code
client", mais vu l'utilisation, ça revient plus à une "autre façon de
déclarer une variable", un peu comme la gestion des block en C++ qui
permet de contrôler le moment ou le destructeur d'une variable
automatique sera appelé...
Si on regarde le problème de plus prêt, quels sont les resources non
managés critiques?
- Les fichiers, il faut alors appelé "Close" (ou using), en C++ on peut
le faire grâce au destructeur, c'est vrai que c'est une étape en plus.
- Les connexions réseaux, même genre de délire.
- Les bases de données: toujours pareil, mais le connection pooling
"automatique" de .NET vient aider la dedans... l'approche déconnectée
aussi.
- La mémoire: le garbage collector fait relativement bien son boulot, il
faut juste penser à ce qui reste visible (en général remplace un "delete
machin" en "machin=null" est une bonne idée ;). Il existe aussi quelques
astuces (weak references par exemple) permettant d'avoir un contrôle
plus fin. Pour la gestion "avancée" par contre (genre memory mapped
file), c'est moins drôle...
- Je dois surement, vu l'heure oublier quelques trucs important, mais ça
ne me vient pas en tête ;)
J'ajouterais que pour l'instant, on manque de recul et d'expérience
sur la "bonne" façon de programer en C# : On a pas encore l'équivalent
d'un Herb Stutter ou d'un Andrei Alexandrescu en C#.
Là on est bien d'accord, cependant, la aussi .NET aide un petit peu: y'a
déjà une série de convention existante, en C++ c'est assez difficile de
trouver une cohérence... cependant, le problème reste toujours, on peut
trouvé des lib .NET qui ne les respecte pas, on peut trouver un design
différent, etc...
> .. en tous cas y'a déjà pas mal d'erreur
> que tu ne pourras pas faire en C#...
Oui, mais certaines choses gérables en C++ (libération des ressources
non managées en autres) ne le sont pas en C#.
Via "using" et un code propre relativement, tu te retrouves en gros avec
un équivalent des variables automatiques, il y'a aussi le "finally" qui
sauve souvent la mise... évidemment, il reste le défaut qu'un
développeur peut oublier tout cela, et son programme "fonctionnera"
(avec un working set de 200Mo ;).
En bref: vivement les methodes anonymes, les generics et les enumerator!
;)
wrote: > (d'ailleurs qu'est ce qui existe comme framework > C++ élégant, moderne, portable???) Si on parle de GUI, il y a WxWindows.
Le prob est que ça ne fait "que" la GUI, si tu veux gérer des bd, de l'xml, un chtit peu de réseau, une GUI windows et une interface web, tu te retrouves à accumuler les libs :-/ (et faut en trouver de bonne portable, s'adapter, s'assurer qu'elles fonctionnent entre elles, etc...).
> et je pense qu'il est plus simple de programmer > correctement en C# qu'en C++. Là j'en suis moins sûr : je vois au moins 2 gros défauts à C# pour des développeurs "avancés" : - Le modèle de compilation du C# rend les (re)compilations pour de très gros projets difficile à gérer et potentiellement très longs (même si le compilo est rapide). Dans certains contextes (recompilation centralisée des modifs faites par toute l'équipe chaque nuit par exemple), çà peut être prohibitif.
Là je suis d'accord, cependant on commence à voir apparaitre des solutions de compilations (hippo.net par exemple). Mais j'avoue ne pas vraiment d'expérience dans ce domaine, je n'ai pas de gros projet C#, et j'avoue aussi ne jamais avoir joué avec de vrai gros projet C++, naivement je me dis pourtant que c'est "gérable", le framework est en grande partie du C# et il me semble qu'on peut le qualifier de "gros projet".
Cependant, je reconnais volontier que le côté "magique" de la gestion des références de .NET peut rapidement mené à de longues compilations, mais en général, une bonne découpe en dll résoudra cela (et ça c'est un gros plus par rapport à Win32, pouvoir exposer des classes de façon vraiment transparente via une dll...).
- Impossibilité de garantir une libération automatique des ressources non managées sans se reposer sur le code client (il y a bien IDispose, mais c'est un pis-aller).
Oui et non, en fait le problème du garbage collector, c'est qu'on le présente comme un "il ne faut pas gérer la mémoire, c'est fait pour toi", ce qui n'est évidemment pas le cas! Le C# offre quand même "using" qui permet d'être relativement propre. En effet c'est "du code client", mais vu l'utilisation, ça revient plus à une "autre façon de déclarer une variable", un peu comme la gestion des block en C++ qui permet de contrôler le moment ou le destructeur d'une variable automatique sera appelé...
Si on regarde le problème de plus prêt, quels sont les resources non managés critiques? - Les fichiers, il faut alors appelé "Close" (ou using), en C++ on peut le faire grâce au destructeur, c'est vrai que c'est une étape en plus. - Les connexions réseaux, même genre de délire. - Les bases de données: toujours pareil, mais le connection pooling "automatique" de .NET vient aider la dedans... l'approche déconnectée aussi. - La mémoire: le garbage collector fait relativement bien son boulot, il faut juste penser à ce qui reste visible (en général remplace un "delete machin" en "machin=null" est une bonne idée ;). Il existe aussi quelques astuces (weak references par exemple) permettant d'avoir un contrôle plus fin. Pour la gestion "avancée" par contre (genre memory mapped file), c'est moins drôle... - Je dois surement, vu l'heure oublier quelques trucs important, mais ça ne me vient pas en tête ;)
J'ajouterais que pour l'instant, on manque de recul et d'expérience sur la "bonne" façon de programer en C# : On a pas encore l'équivalent d'un Herb Stutter ou d'un Andrei Alexandrescu en C#.
Là on est bien d'accord, cependant, la aussi .NET aide un petit peu: y'a déjà une série de convention existante, en C++ c'est assez difficile de trouver une cohérence... cependant, le problème reste toujours, on peut trouvé des lib .NET qui ne les respecte pas, on peut trouver un design différent, etc...
> .. en tous cas y'a déjà pas mal d'erreur > que tu ne pourras pas faire en C#... Oui, mais certaines choses gérables en C++ (libération des ressources non managées en autres) ne le sont pas en C#.
Via "using" et un code propre relativement, tu te retrouves en gros avec un équivalent des variables automatiques, il y'a aussi le "finally" qui sauve souvent la mise... évidemment, il reste le défaut qu'un développeur peut oublier tout cela, et son programme "fonctionnera" (avec un working set de 200Mo ;).
En bref: vivement les methodes anonymes, les generics et les enumerator! ;)
